On Jul 19, 2013, at 3:10 PM, Yaron Sheffer
<yaronf.i...@gmail.com<mailto:yaronf.i...@gmail.com>> wrote:
Hi,
the comments below are focused on the protocol, rather than on its fit with our
requirements. So in a sense I'm jumping the gun here.
Summary
First, the document is very well written, actually fun to read. It presents a
relatively simple solution which I personally find advantageous, and seems to
cover most of the associated issues.
Thanks.
Where I suspect that we have a problem is in the policy definition, for
cross-domain scenarios. I think the currently proposed solution is simplistic,
and I realize that a fuller one could easily turn very complex. Specifically
the peers in the current proposal simply compare the shortcut request with each
peer's SPD for traffic to the *suggester*. Viewed architecturally, this seems
to me like mixing the control and the data plane (you cannot have a suggester
that's not a valid gateway with a valid SPD). Even if we decide this is a good
thing, it might not work in weirder cases like overlapping IP networks.
We'd be happy to hear about those weirder cases. In all cases that we
considered, traffic from A to C was flowing through B. B "introduces" A to C so
that the traffic can flow directly. The SHORTCUT doesn't come out of the blue,
but is a response to existing traffic. This is easy to do when B is in the data
path, and it also makes policy relatively straightforward. If you trust certain
traffic to go through B, you should also trust that same traffic to go through
some other party that B delegated this traffic to (we don't use the word
"delegate" in the draft, but maybe we should).
A non-GW suggester would have to receive real-time traffic reports from B, and
also be trusted by A and C to change their SPD. This is believable within an
administrative domain, but very much not so between domains. This external
suggester would also have to be capable of bi-directional communications, as it
receives data from B and sends data to A and C. So all the NAT issues and
firewall issues come up. We think that adds a lot of complexity. Also, just
because the shortcut messages use the IKE syntax and the IKE keys, and are
co-located with the IKE/IPsec stack does not make this a mixture of control and
data planes. The shortcut messages are entirely control plane, while the IPsec
traffic that follows is entirely data plane.
Details
• Why send the notification to both peers? This creates a race condition, and
the data is only informational anyway, i.e. trust may not be required.
We assume that the peers don't know each other. So you have to supply them with
PAD entries. The shortcut to one peer tells it to be an initiator while the
other is told to be a responder. To avoid the race, all you have to do is to
first tell the responder, and only when it ACKs do you tell the initiator.
• Suggester not a good word. Do we have a better one? Supplicant :-) ?
Supplicant is taken (thank $DEITY). Until a week before we submitted the draft,
we called it a "shortcut starter", but we kept confusing "starter" with
"initiator" so we changed the term. delegator? cut-shorter?
• Why send the VID in IKE_AUTH and not in IKE_SA_INIT?
Agree.
• The VID (if at all used) should be temporary, until the RFC is published.
OTOH I suggest to have a "supported" notification defined immediately,
otherwise we cannot add it later.
The VID is only to facilitate testing, and is actually required for using
private-space notifies. Of course, this will be replaced by a "support"
notification before this document advances.
• Notification of shortcut success can take 10 sec. Is it still useful?
The success or failure notifications have little value for the suggester
anyway. They are very useful for logging. If the administrator can look at a
log and see that all shortcuts suggested with gateway E failed but traffic
still flowed between the center gateway and E, then something is weird about
the E's attachment to the network, and this should be checked and perhaps fixed.
• Why are the traffic selectors for the shortcut related to the TS between the
suggester and the two peers? This precludes the case that the suggester is an
off-line "controller", which does not see the actual traffic.
If it doesn't see the traffic the only thing it can do is try to create a mesh.
We don't think that's useful in large configurations.
• 3.4: the Critical bit is in fact set.
Why? The Notify payload is defined in 5996 and all payloads defined there have
their critical bit unset.
• 3.4: should not use a private value in the draft. I suggest to have a TBD
here, and to mention in the IANA Considerations section that the value
currently being used is this one.
OK.
• These are not "IPv4" or "DNS" shortcuts. The IPv4 and DNS are just fields in
the shortcut definition, and do not make any difference to the shortcut's
behavior. I would suggest to have a single type of shortcut, and to use a third
ID-like field for the address of the target of the shortcut.
• Validity of the PSK: is it valid for the entire duration set by the
suggester? Must it be deleted thereafter? Note that the PSK may be reused if
the peers tear down the IKE SA or it is disconnected.
We should probably fix the language there. But the PSK is valid as long as the
timeout in the SHORTCUT regardless of how many times the the IKE SA has been
torn down and set up again. If a second SHORTCUT is set up with the same peer,
the new PSK replaces the old PSK and sets the timer if the identifiers are the
same, but it does not cause existing SAs to be torn down.
• 3.4.1: Sending the IDr (by the initiator) is not normally mandatory in IKEv2.
I think here it should be.
Good idea.
• 3.4.2: why does the IPv6 Address field appear 4 times in the diagram?
Because it takes 4 32-bit rows?
• 3.4.3: 12 octets -> 2 octets
Right
• 3.4.3: the recommendation at the end of the section is strange: why is it
tied to certificate authentication? A peer presents its ID when authenticating
with a PSK, too.
Yes, there's something missing there. I think it was supposed to be a
suggestion that the *certificate* have the same FQDN, similar to HTTPS.
• Response Shortcut: I would prefer a separate Shortcut-Response notification,
since this is not a real shortcut of course. Moreover, rather than matching a
large number of strings, it's much more convenient to tag each shortcut
suggestion with an ID, and include this ID in the response.
Good idea. That will also allow us to have a SHORTCUT delete message if for
example, the responder agreed to the shortcut, but the initiator refused.
• 3.5.2: the last sentence (to do with timeouts) is unclear.
s/shortcut partner to the timeout/shortcut partner prior to the timeout/
• 3.5.3: why are shortcuts a "service" that can be disabled? What is the
benefit?
With AD-VPN the behavior of the gateways is less predictable. It is far easier
to trouble-shoot why traffic is not getting to the other side if the SPD is
fixed. Also, using AD-VPN makes you dependent on correct implementation of
AD-VPN in gateways you have never heard of. Disabling AD-VPN might fix the
issue.
• 3.5.5: typo: UNMATCHED_SHORTCUT)_SPD
• 3.5.5: the SPD lookup applies to additional things, not only to IP address.
Yes, I guess it is the traffic selectors that matter here.
• 3.5: If as an Initiator/Responder I don't like the suggestion that I have
received, but I don't want to leak details of my security policy, is there a
generic error I can use?
Not currently, but wouldn't a new generic error signal just that?
Thanks,
Yaron
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
