Last Call Review of draft-ietf-6man-multicast-addr-arch-update-05

Request Review of draft-ietf-6man-multicast-addr-arch-update
Requested rev. 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 rev. 05 (document currently at 08)
Review result Has Issues
Review completed: 2014-07-03


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