On Sun, 11 Jan 2015, Yaron Sheffer wrote:
I sent Valery an updated version which he can hopefully incorporate in
this WGLC. I'll just comment on Yaron's remarks below.
- Unclosed sentence in the abstract: "It may be used to preserve anonymity
of"
I suggested a rewriten abstract to Valery.
- Reference to IKEv2: please use RFC 7296.
Did that.
- 2.1: it may be trivial, but we want to add that the AUTH payload MUST be
verified by the recipient.
Sure.
- 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."
I think you mean to say the NULL Authentication Method does not require
ID_NULL. But obviously ID_NULL cannot have a payload. Because if you
give it one, what type would it be? :P
- "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?
These issues are difficult and need to be addressed in the "opoprtunistic
ipsec" document. I'm not sure how much of this discussion belongs in
this document. I would prefer if this document keeps it focus on the
format of the Null Authentication Method and ID_NONE payloads.
(I think what I put in my suggestions to Valery is already too much for
this document)
If you have more peers behind the same NAT, you need a GOOD strategy for
containing those private IPs or else one of those clients is going to
use 8.8.8.8 and steal the servers DNS traffic.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
