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

From: Yaron Sheffer <[email-masked]>
Date: Fri, 19 Jul 2013 15:10:31 +0300

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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 22 Jul 2013 19:28:21 +0000

On Jul 19, 2013, at 3:10 PM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> 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?

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.

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?

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.

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 24 Jul 2013 16:45:42 +0400

Hi,

a few comments on the draft-sathyanarayan-ipsecme-advpn-00.

1. Why not include port along with IP address of endpoint
    in shortcut notification? This will allow creating shortcuts
    in some of the situations when both endpoints are behind NAT,
    but at least one of them has some knowledge about the
    external address and port it is reachable on (or it can
    open port on FW/NAT via some protocol). Endpoint, selected
    as responder, may return this information to suggester in response to 
    create shortcut notification and suggester will pass it 
    to the other endpoint in corresponding create shortcut notification.

2. Draft says nothing about using of internal addresses when
    creating and using shortcuts. If endpoint got internal address
    via CP Payload when it created SA with GW, what should
    it do when GW requests it to create shortcut? I think,
    it must not request new address via shortcut IKE SA
    (as it is useless in most cases) and must use the address, obtained
    from suggester GW as its internal address for shortcut?

3. It seems that shorcuts must always be in tunnel mode, even in p2p case?

4. I agree with some of Yaron's comments, in particular:
    - use "supported" Notification instead of VID
    - use separate Shortcut-Response

Regards,
Valery Smyslov.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 25 Jul 2013 20:04:05 +0200

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

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

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

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

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

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

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

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

---

From: Yoav Nir <[email-masked]>
Date: Fri, 26 Jul 2013 11:55:55 +0000

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

The Quicker Shorter Cutter

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

We'll consider this when we're working on -01. It's a slight change in syntax.

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

In HTTPS, they match the FQDN used to look up the server with the names in the certificate. I always expect that in IKE, the certificate will match the ID payload. But scanning through RFC 5996, I don't see such a requirement anywhere. In face, according to section 3.7, the only requirements are:

   o  is configured to use certificate authentication,

   o  is allowed to send a CERT payload,

   o  has matching CA trust policy governing the current negotiation,
      and

   o  has at least one time-wise and usage-appropriate end-entity
      certificate chaining to a CA provided in the CERTREQ.

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Sat, 27 Jul 2013 13:38:53 +0000

Hi Valery,

Thanks for the review and comments. Our response inline.

-- Praveen

>    to the other endpoint in corresponding create shortcut notification.

[PRAVEEN] We did explore about this just few weeks before we were
submitting the draft. This is something like how STUN protocol would work.
I am no NAT expert. What I understand from reading STUN protocol is that,
it solves most NAT situation, for example symmetric NAT. Thus we wanted to
explore if there are other solutions, that may resolve in all NAT
situations. Because of time constraint, we didn't rush to include in -00
draft. But definitely this is something that we are looking for -01 draft.

>    from suggester GW as its internal address for shortcut?

[PRAVEEN] Yes. Shortcut partners must use internal address for shortcut
(at it is the address suggested by suggester). But we are not sure if it
covers every scenario.

>3. It seems that shorcuts must always be in tunnel mode, even in p2p case?

[PRAVEEN] I am not sure about the use case where transport-mode could be
useful. May be when other tunneling protocol is used like GRE. So, when
Shortcut suggester sees traffic from one GRE tunnel going to another GRE
tunnel, it may send SHORTCUT notification to shortcut peers, with a
traffic-selector which has single IP address. Then, shortcut initiator may
choose to trigger shortcut tunnel negotiation with transport mode or
tunnel mode. If transport mode was chosen, as transport mode is optional
in IKEv2, if shortcut responder does not agree, a tunnel mode will be used
for shortcut tunnel.

>    - use separate Shortcut-Response

[PRAVEEN] We agree as well. We are considering above Yaron's suggestions
in future revision draft.

>
>Regards,
>Valery Smyslov.
>
>_______________________________________________
>IPsec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ipsec
>
>