Subject: Re: [secdir] Secdir review of draft-ietf-6man-multicast-addr-arch-update-05

From: <[email-masked]>
Date: Thu, 3 Jul 2014 12:03:46 +0000

Dear Charlie,

Thank you for the review. 

Please see inline. 

Cheers,
Med

>-----Message d'origine-----
>De : Charlie Kaufman [mailto:[email-masked]]
>Envoyé : samedi 28 juin 2014 07:11
>À : [email-masked]
>Cc : [email-masked];
>[email-masked]
>Objet : Secdir review of draft-ietf-6man-multicast-addr-arch-update-05
>
>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.

[Med] Great, thanks.

>
>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.

[Med] FWIW, this is in part one of motivations for this draft (see the examples provided in Section 3 of the draft). This document reiterates that flag bits are to be treated as separate bits. Remaining flag bits that are not associated yet with a meaning can be set to 0 or 1. After checking the text, I found this is clearly mentioned for X but not for r bits. I made a change for r bits (see below)   

>
>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.

[Med] I agree with your point. I suggest to remove that sentence from the UPDARED text because valid P&T values when R is set are clearly indicated. 

>
>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.

[Med] Ignoring an undefined flag or expecting an undefined flag to be set to 0 or 1 have the same consequences, no? Explicitly saying an undefined flag can be set to 0 or 1 is IMHO superior in case an implementation does not treat flags as separate bits acts on prefix ranges. 

 But it should
>specify that it MUST be sent as zero. 

[Med] This does not apply for this specification because this will lead to exclude a range of valid addresses for a given flag; see the example in Section 3.

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.

[Med] Good point. I made this change:

OLD:
      where "rrrr" are for future assignment as additional flag bits.

NEW:
      where "rrrr" are for future assignment as additional flag bits.
      r bits may each be set to 0 or 1.
>
>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