Hi Paul, Valery,
Please see below.
Thanks,
Yaron
On 01/11/2015 06:34 PM, Paul Wouters wrote:
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.
If there's a newer and cleaner version of the draft, can you please
submit it to make all our lives somewhat easier.
- 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
Agreed. I would prefer the NULL Authentication Method to not require
ID_NULL.
- "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.
I tend to agree. But in that case, the above two points need to be
removed from the draft. And a more detailed (non-normative!) placeholder
added to the Security Considerations, so that until we have an
"opportunistic IPsec" draft, people will know where the minefields are.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
