Hi Valery,
Please see my comments below.
- Unclosed sentence in the abstract: "It may be used to preserve
anonymity of"
- Reference to IKEv2: please use RFC 7296.
- 2.1: it may be trivial, but we want to add that the AUTH payload MUST
be verified by the recipient.
- I don't think that we have consensus on "The Identification Data in
Identity payload for the ID_NULL type MUST be absent". The asserted but
unproven identity may be used for logging, or may be proven with a later
authentication. Quoting from an email by Tero: "I think the most
important point of this feature is that the client is UNAUTHENTICATED,
not that it is ANONYMOUS."
- "If endpoint receives a request to create an unauthenticated IKE SA
from the IP address, which is configured on the endpoint to be
authenticated, the request SHOULD be rejected." - I don't see why. What
if there are several peers behind an IP address, some authenticated and
some not? Maybe we need to think some more about the policy that each of
the peers should enforce.
- The issue of Traffic Selectors needs better treatment. Should we add a
MUST for allocation of internal IP addresses?
Thanks,
Yaron
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
