Skip to main content

Last Call Review of draft-ietf-6man-multicast-addr-arch-update-05
review-ietf-6man-multicast-addr-arch-update-05-secdir-lc-kaufman-2014-07-03-00

Request Review of draft-ietf-6man-multicast-addr-arch-update
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-07-02
Requested 2014-06-19
Authors Mohamed Boucadair , Stig Venaas
Draft last updated 2014-07-03
Completed reviews Genart Last Call review of -05 by Ben Campbell (diff)
Genart Telechat review of -07 by Ben Campbell (diff)
Secdir Last Call review of -05 by Charlie Kaufman (diff)
Assignment Reviewer Charlie Kaufman
State Completed
Review review-ietf-6man-multicast-addr-arch-update-05-secdir-lc-kaufman-2014-07-03
Reviewed revision 05 (document currently at 08)
Result Has Issues
Completed 2014-07-03
review-ietf-6man-multicast-addr-arch-update-05-secdir-lc-kaufman-2014-07-03-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document tightens the wording around the usage of flag bits specified in
RFCs 3306 and 3956. I don't believe it would require changes to any existing
implementations, and it would be a real stretch to claim it has any security
implications at all. The document's security considerations section references
the security considerations sections of other documents. This seems appropriate.

This document addresses an issue that I personally am very passionate about,
and I believe this document takes what is already a bad situation in those
earlier RFCs and makes it worse. (It is possible there is some subtlety in the
issues surrounding IP Multicast Addresses that makes my arguments invalid, but
please hear me out and think about it.)

There are too many documents that have fields labelled "flags" or "undefined"
or "reserved for future use" and they expect implementers to do the right thing
with them. Documents should always specify what a sender should send and what
recipients should do with received values. A good default policy for
implementers to follow is to always send packets with such fields set to zero
and always ignore values seen in these fields. But if that is the desired
policy, the spec should say so, and there are times when a different policy
makes more sense. For example, it might also be useful to have a reserved for
future use field where a sender always sends zero and a recipient treats any
message containing a non-zero value as invalid. That would allow a new
implementation to send a message that another new implementation would process
correctly and an old implementation would reject as invalid rather than
processing incorrectly.

The reason for specifying behavior carefully is that future revisions to the
protocol may want to encode information in these fields, but to do so safely it
must be possible to predict what existing implementations will do when
interacting with the new ones. That is only possible if we know what existing
systems are going to send and what existing systems will do when they receive
newly defined values.

RFCs 3306 and 3956 break these rules by saying things like "The behavior is
unspecified if P or T is not set to 1". Behavior should never be unspecified.
Either the values of P and T should be ignored, or the address should be
treated as invalid if P or T is not set to 1, or some other behavior should be
specified. The sender should have a specified behavior of always setting them
to 1.

This I-D, while trying to correct some ambiguities, actually makes it worse. It
says things like "X may be set to 0 or 1" (where X is a flag bit). It would be
fine to say X MUST be ignored on receipt. But it should specify that it MUST be
sent as zero. Otherwise, implementations of the spec are free to set it to zero
or one and no future modification to the protocol can ascribe any meaning to
the value set because when interoperating with an old implementation the
received value is unpredictable and meaningless.

It divides a 4 bit "reserved" field into four 1 bit "flag" fields, but still
does not specify what values those flags should be set to (presumably zero) nor
what an implementation should do if they are non-zero on receipt (perhaps
ignore them, or perhaps reject the address... I can't guess the intent.

It might be too late to do an optimal job of specifying the desired behaviors
with respect to these flags because that might "break" existing
implementations. But we certainly shouldn't make it worse by permitting useless
flexibility unless it was already promised in the earlier documents.

        --Charlie Kaufman