Hi Valery, Paul,
I re-read the new draft and I must say it is much clearer than the
previous version. Still, a few comments:
- Please spell-check the draft. There are numerous typos.
- The "privileged IKE operations" is obviously a bit thin.
"Initial Contact" may be a good example of an operation that
we'd be better off without. But if we don't have any specific
examples, let's remove this section.
- Implementations MAY force... to single host-to-host IPsec SAs.
If we cannot come up with a good way for an unauthenticated peer
to prove ownership of SA ranges (whatever "ownership" might mean
in this context), then I guess we should change the MAY into a
SHOULD.
- We are still using IP addresses to identify peers: "if an IKE
peer receives... from an IP address that matches a configured
connection". I think an IKE peer that supports null auth should
be able to distinguish peers depending on other characteristics,
and should be able to handle mixed configurations/policies even
for a single IP address.
- I suggest adding this short subsection to the Security
Considerations:
Although this document discourages the use of non-null ID
payloads to identify an unauthenticated peer, IKEv2 provides
channel bindings capabilities and those may be used to
authenticate this identity at a later time, while binding the
authenticated identity with the original IKE exchange. This
applies to a related but distinct use case, where peers cannot be
authenticated at the time of the exchange but do not wish to
remain anonymous. Please see [AutoVPN] for one way of
after-the-fact authentication of an IKE peer.
[AutoVPN] draft-sheffer-autovpn, 2014.
|
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
