Re: [IPsec] Comments on draft-sathyanarayan-ipsecme-advpn-00

[Yaron Sheffer <[e-mail]>]

Hi Yoav,

sorry for the delayed response, but hey, what's an airplane for? Please 
see below.

	Yaron

On 2013-07-22 21:28, Yoav Nir wrote:
>
> On Jul 19, 2013, at 3:10 PM, Yaron Sheffer <[e-mail]
> <mailto:[e-mail]>> 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.

I agree this removes a whole lot of complexity. I'm just not convinced 
it's good enough for real-world use. The control/data thing is just an 
analogy: you need to be on the path in order to control it.

>
>> 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.

So let's mandate this order.

>
>> • 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?
>

"Manager" (half-smile)? Never mind.

>> • 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.

Of course. Sorry.

>
>> • 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.

You did not comment on this point. Please consider a rearrangement of 
the various shortcuts.

>> • 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.

This all should be noted in the draft.

>
>> • 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.

But then again, we don't do that in IKE (though maybe we should have).

>
>> • 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.

OK, but is there a useful difference between a gateway where AD-VPN was 
disabled and one that doesn't support it? Eventually the gateway 
operators need to talk to one another :-)

>
>> • 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?

Yes and no. There are two quite specific responses, unmatched PAD and 
unmatched SPD. I would have liked a "Shortcut Refused", too.

>
>> Thanks,
>>     Yaron
>>
>