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
No implementation should depend on the order of payloads for anything.
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.
Actually I now noticed you changed the "SHOULD be ignored" to "MUST be
ignored", and I think that is again bad idea. I think logging and
auditing the ID for problem solving purposes is good idea even if it
does not have any meaning for the authentication. I.e. at least then I
can contact helpdesk and say that my NULL authentication connection to
server 1.2.3.4 failed, and I have no idea why, can you help. Oh, my ID
payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it
from your logs...
Actually, I tried to address Paul Wouters' concern that without
strong "MUST" here implementations may use ID even if it is
not authenticated. But, from my understanding of the wording,
"MUST be ignored by IKE" doesn't mean that implementation
is not allowed to log the ID, that is always useful ror auditing
and troubleshooting. I probably should make this more clear.
And I feel that I need to reject anonymous connections that have an ID
to protect the anonymity of the user.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
