|
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. 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. 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. • Suggester not a good word. Do we have a better one? Supplicant :-) ? • Why send the VID in IKE_AUTH and not in IKE_SA_INIT? • 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. • Notification of shortcut success can take 10 sec. Is it still useful? • 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. • 3.4: the Critical bit is in fact set. • 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. • 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. • 3.4.1: Sending the IDr (by the initiator) is not normally mandatory in IKEv2. I think here it should be. • 3.4.2: why does the IPv6 Address field appear 4 times in the diagram? • 3.4.3: 12 octets -> 2 octets • 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. • 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. • 3.5.2: the last sentence (to do with timeouts) is unclear. • 3.5.3: why are shortcuts a "service" that can be disabled? What is the benefit? • 3.5.5: typo: UNMATCHED_SHORTCUT)_SPD • 3.5.5: the SPD lookup applies to additional things, not only to IP address. • 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? Thanks, Yaron |
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
