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