Paul Wouters writes: > On Tue, 4 Mar 2014, Valery Smyslov wrote: > > > I agree this may chocke some implementations. The idea was that > > if implementation notice that Auth Method is NULL, it must > > not parse ID Payload at all. But I understand that depending > > on the order in which payloads are processed by particular > > implementation, this may be inconvinient for implementers. > > I have actually thought about a mode where we scramble the order or > payloads just to see which implementations would die :P
That only works for RFC5996 version, RFC4306 version are allowed to reject packets which have payloads in "wrong" order: >From RFC4306: ---------------------------------------------------------------------- 2.5. Version Numbers and Forward Compatibility ... Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations MUST send the payloads defined in this specification in the order shown in the figures in section 2 and implementations SHOULD reject as invalid a message with those payloads in any other order. ---------------------------------------------------------------------- RFC5996: ---------------------------------------------------------------------- 2.5. Version Numbers and Forward Compatibility ... Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations SHOULD send the payloads defined in this specification in the order shown in the figures in Sections 1 and 2; implementations MUST NOT reject as invalid a message with those payloads in any other order. ---------------------------------------------------------------------- > No implementation should depend on the order of payloads for anything. True, but for example my implementation do parse all payloads first, and then start processing them by first checking certain payload, then checking the payloads in suitable order (i.e check that all require payloads are there, then check whether payloads have suitable values etc). This is done just this way so it does not matter in which order the payloads in the incoming packets are. I will find the ID payload regardless where it is, when I need it. And for example my ID parsing code already checks that there must be 4 bytes of data, if the ID type is ID_TYPE_IPV4_ADDR, and will return error immediately there if that is not true. This is way before I even start checking what is the authentication type etc. Of course I could move that checking to later, i.e when actually using the ID payload, but that would have its own issues. > > and require implementations to use it if they want to keep anonimity. > > I feel someone wants to give an implementation the freedom to make an > unwise decision :P I really want to insist that anonymous means > anonymous - no methods for sending along an ID. This is not anonymous method, this is unauthenticated method. We cannot really provide anonymity with this method. > And I feel that I need to reject anonymous connections that have an ID > to protect the anonymity of the user. But should you reject unauthenticated connections just because they have ID which you are not authenticating anyways. Note, that we are talking about unauthenticated connections, not really anonymous connections. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
