I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive. Since this is now scheduled for next weeks telechat, you
should liaise with your AD before making any changes.
Document: draft-ietf-manet-packetbb-11.txt
Reviewer: Elwyn Davies
Review Date: 18 January 2008
IETF LC End Date: 16 January 2008
IESG Telechat date: 24 January 2008
Summary:
This document is not ready for the IESG.
There are issues that must be addressed:
- There are parts of the packet format that are not fully specified (encoding
of lengths not specified particularly).
- The supposed extensibility is currently chimeric.
The relationship between this draft, OLSR [experimental, RFC 3626] and OLSRv2
[aiming for ps, draft-ietf-manet-olsrv2-04.txt] should be made clearer. OLSR
packet format has very little to do with the current work whereas OLSRv2
explicitly uses the format specified here.
The inconsistency of the polarity of the inclusion/exclusion bits in the
various semantics fields is ugly, unnecessary and likely to cause grief for
implementers who get mixed up, as well as making the document difficult to
read. It would be good to fix this before OLSRv2 progresses further.
The layer violation required to obtain the notional address length from the
lower level protocols is unpleasant. I would like to see an optional field to
carry this value explicitly that (a) avoid the layer violation and (b) make the
format usable where the network layer protocol is not a conventional IP
protocol (e.g. when the format is used in a DTN environment).
Personally I would prefer to see ABNF used to specify the packet grammar. It
is common IETF usage and generally more familiar to standards readers than
regular expressions.
Apart from these major issues, there are a number of more detailed comments
below and a few editorial nits.
Comments:
s1/general: While the use of regular expression formalism to express the
packet content grammar is perfectly valid, the IETF normally prefers to use
ABNF [RFC2234] to express grammars of this kind. Since the very limited subset
of RE that is actually used could be equally expressed in ABNF, consideration
should be given to using ABNF. This could be automatically checked and is
likely to be more familiar to the general reader. Also a number of items in
the terminology could then be removed.
s2: The 'Network Address' is confusing and not really fully defined. I presume
that it is supposed to be the same as what is usually called an address prefix.
The exact interpretation of 'prefix length' needs to be spelt out (presumably
that only that number of address bits measured from the left/most significant
end of the address are significant).
s2: address-length: Although address-length can be imputed from the network address fields of (IP) network layer if that is being used, it would make the format more genrally useful (I am thinking maybe DTNs here) if there as an optional field in the packet header (?) to carry the address-length explicitly. That would also avoid forcing layer violations.
s3: I sort of assumed from the statement that the protocol was derived from OLSR (an experimental proto, [RFC3626]) that the header compression ideas came from there and hence that there was a good deal of history that needed to be (or at least could conveniently be) brought over. I believe that in practice there is relatively little propagated and some of the choices on this document are not the result of any history - see particularly comments on 'polarity' of semantics flag bits. OTOH, it appears that OLSRv2 which is still a draft progressing towards PS explicitly uses this format.
s3, para 2 and s7: There are security concerns with using IPv4 mapped IPv6
addresses, especially 'on the wire'. Technically this usage is not on the
wire, I guess, but I think it would be good to point out and justify that the
security concerns do not apply (see [RFC4942] for discussion - also you can go
back to
http://www.watersprings.org/pub/id/draft-itojun-v6ops-v4mapped-harmful-02.txt
to see the original discussion at more length).
s3, para 5: I am less convinced about the extensibility of the protocol than the authors seem to be because there is no mechanism for specifying behaviour when a receiver sees either messages or TLVs that it does not recognise. A number of relatively standard techniques exist involving emebedded flags specifying drop/ignore packet/message if unrecognized, forward/drop message if unrecognized, etc
s3, last para: I believe the 'may' could be a MAY.
s3, last para: AFAICS the example feature is not well chosen as the diffusion mechanism is orthogonal to the packet syntax specified here. If there are things about the packet format that might be called features that could be constrained, one of these should be selected as an example. Otherwise delete the 'features' comment.
s4: Sections 1, 3 and 4 are not consistent about the applicability of the
format. s4 says it could be used by any protocol (but particularly ad hoc
routing protocols), s3 says it is just for MANET routing protocols, and s1 says
it is for any protocol running between MANET routers. Please make up your minds!
s5.1/s5.2/s5.4/s5.5: Inconsistent semantic flag bit polarities: I cannot see a good reason why some bits are '0' if the the field is *ex*cluded and others are '0' if the field is *in*cluded. My initial thought from s3 was that maybe this was some inheritance from OLSR, but AFAICS OLSR doesn't have any of the packet compression capabilities. For a format that is supposed to make decoding easy, this is not a clever design choice IMO. If there is no real reason for the choice, it would be much easier both to read and for the implementer, and less likely to make for implementation errors if they all had the same polarity.
s5.1 etc: Do the semantic bits need IANA registries? I suspect this is not
vital. AFAICS they cannot be used as part of the extensibility so they could
only be defined as part of a new version of the format with a different version
number.
s5: Reserved semantic bits: Forcing the reserved bits as 'MUST be 0'
constrains extensibility and goes against usual practice. In the usual way it
would be better to specify 'SHOULD be 0 on transmission and SHOULD be ignored
on reception'.
s5.1: <pkt-size>: needs to specify how it is carried (presumably an unsigned
integer, and it would be sensible to spell out that it includes all the octets that make up
the <packet> rather than just saying it 'specifies the size of the packet' - that
*could* be interpreted in other ways.
s5.1: pkt-size (variable): This is the first time 'network or transport
protocols' are mentioned. A discussion in s3 of how this sort of payload might
be carried would be a good idea.
s5.2: <msg-type>: This should refer to the relevant IANA registry defined
later.
s5.2: <msg-size>: Same as comments for <pkt-size>
s5.2: <msg-hop-limit>, <msg=hop-count>, <msg-seq-num>: Need to specify how each
value is carried.
s5.4: Length fields and <num-addr>: Need to specify how each value is carried.
s5.4: mid-length variable: '==' is C programming language jargon rather than standard maths. s/==/is equal to/
s5.5/s5.5.1: need to specify how all length values are carried and how <tlv-type> and <tlv-type-ext> are to be interpreted as numbers when needed.
s6.1: I do not believe the statement that OLSR is compatible with this packet
format so there seems little point in reserving message types for it. Note
also that OLSR is not a standard and hence contravenes the registry allocation
policy. On further inspection what is happening here is that OLSRv2 which is
an I-D intended for PS will use these 4 messages and explicitly uses this
packet format. It would be much tidier to eliminate the pre-reservation and
just let OLSRv2 grab the relevant registry entries if and when it achieves PS.
s7: I think I would phrase the intro differently, saying that packet/message integrity are considerations and suggestions are made rather than saying there aren't any. It might also be sensible to point out that the suggestions for message integrity as they stand leave open a DoS attack by a MiTM modifying the hop limit or hop count fields.
Editorial:
general: Expand MANET acronym.
Abstract/Section 1: The term 'multi-message packet format' is not totally transparent. It took me a little bit of reading to see what was implied. It is only used in a few (4) places - I would suggest 'packet format capable of carrying multiple messages' in the abstract and the first instance in s1 and add '("multi-message packet format")' to the first instance in s1.
s2: The term 'Logical Hop' needs to be defined. (There are some words in s3).
s3: The term 'scope limited diffusion' needs to be further defined.
Appendix B: All the pictures need explanatory captions.
_____________
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf