On Tue, 4 Mar 2014, Tero Kivinen wrote:
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:
I did not realise IKEv1 did not allow that. How quaint....
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.
That's exactly how we do it. Parse each payload and store it, throw an
immediate error if any of these are wrong. Then lookup the SPIs, find
the right state and check if all required payloads are there and all
other payloads are valid optional payloads, and only then proceed with
processing.
This is not anonymous method, this is unauthenticated method. We
cannot really provide anonymity with this method.
Okay, I guess we disagree.
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.
Yes I think so. You are changing the meaning of ID from implicitely
"verified ID" to potentially "unverified ID". I think that is wrong.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
