Hi Paul,
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
No implementation should depend on the order of payloads for anything.
The order payloads are processed is not necessary the order payloads
appear in the message. Nobody (at least not me) tells that payloads
must be processed in the order they appear in the message,
but you still process payloads in some order. For example,
you first try fo collect all VID payloads too understand what
non-standard things you may expect from the message,
before you start processing other payloads, don't you?
So, I just meant, that if ID Payload is processed before
AUTH Payload (a very natural behaviour, isn't it?), that implementation
may not be prepared to get "scrambled" ID and it may choke it.
But actually, it doesn't matter, because if implementation supports
NULL Auth, it must be prepared to get any ID,
and if it doesn't, then exchange will fail anyway.
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.
I just want to allow user to keep his anonimity to the extent
he wishes himself. From my understanding the peer, who uses
NULL Auth, must have freedom to decide whether to
put something in ID (for any reason), or leave it empty. And note,
that the draft encourages users (by SHOULD) to do the latter.
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
