--- 1/draft-ietf-manet-timetlv-05.txt 2008-08-01 15:12:22.000000000 +0200 +++ 2/draft-ietf-manet-timetlv-06.txt 2008-08-01 15:12:22.000000000 +0200 @@ -1,20 +1,20 @@ Mobile Ad hoc Networking (MANET) T. Clausen Internet-Draft LIX, Ecole Polytechnique, France Intended status: Standards Track C. Dearlove -Expires: January 11, 2009 BAE Systems Advanced Technology +Expires: February 2, 2009 BAE Systems Advanced Technology Centre - July 10, 2008 + August 1, 2008 Representing multi-value time in MANETs - draft-ietf-manet-timetlv-05 + draft-ietf-manet-timetlv-06 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -25,21 +25,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 11, 2009. + This Internet-Draft will expire on February 2, 2009. Abstract This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. Table of Contents @@ -154,25 +154,25 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Additionally, this document uses terminology from [packetbb], and introduces the following terminology: hop count - the number of hops from the message originator to the - message recipient. This is defined to equal the field - in the element defined in [packetbb], if present, - after it is incremented on reception. If the field is - not present, or in a packet TLV, then hop count is defined to - equal 255. + message recipient. This is defined to equal the + field in the element defined in [packetbb], if + present, after it is incremented on reception. If the field is not present, or in a packet TLV, then hop count is + defined to equal 255. time-value - a time, measured in seconds. time-code - an 8 bit field, representing a time-value. 3. Applicability Statement The TLV structure described in this document is applicable whenever a single time-value, or a time-value that varies with the number of hops from the originator of a message, is required in a protocol @@ -276,23 +276,24 @@ originator node, the time-value indicated is that represented by the time-code: o , if n > 0 and hop count <= ; o , if n > 1 and < hop count <= for some i such that 1 <= i < n; o otherwise, i.e. if n == 0 or hop count > . - If included in a message without a field in its message - header, or in a packet TLV, then the form of this data structure with - a single time-code in (i.e. n == 0) SHOULD be used. + If included in a message without a field in its + message header, or in a packet TLV, then the form of this data + structure with a single time-code in (i.e. n == 0) SHOULD + be used. 6.1. Single-value Time TLVs The purpose of a single value Time TLV is to allow a single time- value to be determined by a node receiving an entity containing the Time TLV, based on its hop count from the entity's originator. The Time TLV may contain information that allows that time-value to be a function of the hop count, and thus different receiving nodes may determine different time-values. @@ -492,33 +493,49 @@ | | | | address is to be considered | | | | | valid | | | | 1-223 | Expert Review | | | | 224-255 | Experimental Use | +---------------+------+-----------+--------------------------------+ Table 2 10. Security Considerations - This document does not specify any security considerations. + This document specifies how to add data structures (TLVs) which + provide timing information to packets and messages specified using + [packetbb]. In particular, information validity durations and + reporting intervals may be added. + + The general security threats that apply are those general to + [packetbb] and described therein, problems of integrity and + confidentiality. With regard to the former, modification of a time + TLV can cause information to have an invalid validity time, or + expected interval time. This may cause incorrect protocol + performance. Modification or addition of timed information can add + to a protocol's workload (especially if a short validity time is + specified) and storage requirements (especially if a long validity + time is specified). + + To counter these threats, the security suggestions in [packetbb], for + the use of authentication and encryption, are appropriate. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [packetbb] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized MANET Packet/Message Format", - draft-ietf-manet-packetbb-13.txt (work in progress), - June 2008. + draft-ietf-manet-packetbb-14.txt (work in progress), + August 2008. 11.2. Informative References [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State Routing Protocol", RFC 3626, October 2003. Appendix A. Acknowledgements The authors would like to thank Brian Adamson and Justin Dean (both NRL) and Ian Chakeres (Motorola) for their contributions, and Alan