Subject: [IPsec] New draft for address ADVPN (draft-sathyanarayan-ipsecme-advpn-00)

From: Praveen Sathyanarayan <[email-masked]>
Date: Sun, 7 Jul 2013 02:05:52 +0000

Hi,

Please find new draft that specifies a protocol to address ADVPN
Requirement (draft-ietf-ipsecme-p2p-vpn-problem-07.txt).

This document proposes a protocol that can demonstratively scale in large
IPsec deployments while ensuring that routing stretch is minimized and
   network resources are used more optimally. The proposed protocol
extends [IKEV2] to meet the requirements spelled out in
draft-ietf-ipsecme-p2p-vpn-problem-07.txt, providing a standard way to
dynamically establish and tear down IPsec tunnels as needed without
requiring non-scalable
   configuration. The protocol introduces the concept of a ³shortcut"
which can be used by compliant IPsec gateways to optimize the
   traffic path between two peers. The protocol has provisions for
adhering to established policies and is applicable to single- and
multi-domain environments. Shortcuts can be established and torn
dynamically and, the proposed solution is applicable to a variety of use
cases and scenarios, pertaining to both wired and wireless networks.

URL: http://www.ietf.org/id/draft-sathyanarayan-ipsecme-advpn-00.txt

Please provide us your feedback.

Thanks,
Praveen

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Jul 2013 19:34:46 -0700

OK, I'll start. Which of the requirements from draft-ietf-ipsecme-ad-vpn-problem do any of the authors believe this proposal meets completely? Adequately? Barely? Not at all?

--Paul Hoffman

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Sun, 7 Jul 2013 02:46:16 +0000

Hi Paul,

FYI

We have "Appendix B Comparison Against ADVPN Requirements². This section
compares draft-ietf-ipsecme-ad-vpn-problem this proposed ADVPN protocol. I
believe, we meet the requirement completely. We welcome your feedback on
it. 

Thanks,
Praveen

On 7/6/13 7:34 PM, "Paul Hoffman" <[email-masked]> wrote:

>OK, I'll start. Which of the requirements from
>draft-ietf-ipsecme-ad-vpn-problem do any of the authors believe this
>proposal meets completely? Adequately? Barely? Not at all?
>
>--Paul Hoffman
>_______________________________________________
>IPsec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Jul 2013 19:51:24 -0700

> believe, we meet the requirement completely. We welcome your feedback on

Sorry, I was being too terse. The appendix lists the requirements, but doesn't say how well the authors think they met or didn't meet each one. Are there requirements you feel that the proposal covers less well than others?

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Sun, 7 Jul 2013 06:29:55 +0000

> Sorry, I was being too terse. The appendix lists the requirements, but doesn't say how well the authors think they met or didn't meet each one. Are there requirements you feel that the proposal cov…

Hi Paul

I don't know if I speak for all the authors, but I think the draft covers all the absolute requirements, as in #2: "ADVPN peers MUST allow IPsec Tunnels to be setup with other members of the ADVPN without any configuration changes, even when peer addresses get updated every time the device comes up.". Yes, our document allows this. Where I feel there is still room for improvement is where the requirements are stated as "should be minimal" or "should be simple". Specifically:

Requirement #1: "For any network topology ... gateways and endpoints SHOULD minimize configuration changes when a new gateway or endpoint is added, removed or changed."
If Endpoint E sends traffic to networks b, c, and d through gateway G, then our protocol allows gateway G to introduce E to another gateway, say H, and to instruct E to send traffic to network c through gateway H. In a hub-and-spoke configuration, that means that endpoint E has to be preconfigured with all of the addresses in the ADVPN. So if we add a gateway (with its associated network) this new network has to be configured on all endpoints. This is not minimal. We are considering two ways of fixing this:
 1. Begin with all traffic going through the hub gateway, and add a "BYPASS" shortcut to tell the gateway about all the traffic that needs not be sent through the hub, or
 2. Introduce a "trusted peer" that can send shortcuts for any traffic selector, not just delegate what our policy already says to send through it.
Feedback about these two options will be highly appreciated.

Requirement #8: work behind NAT. In this version of the document, the gateway sending the SHORTCUT messages (the suggester) has done IKE_AUTH with both spokes, and knows whether one or the other is behind NAT. If one is behind NAT and the other is not, it can tell the one behind the NAT to be the initiator. If both are behind NAT, it can and should avoid suggesting a shortcut. We think this can be improved upon. After all, VoIP applications such as Skype manage to work pretty much anywhere where there isn't a firewall that is actively blocking them. We have considered adding NAT traversal mechanisms such as STUN, but we need to get more knowledge on the subject before we're ready to add this to our solution.

Requirement #15: per-peer QoS. Our protocol does not prevent peers from setting up multiple tunnels for multiple QoS classes. However, the SHORTCUT notification does not contain any QoS policy. So assuming that peer A learned of peer C through a message from peer B, it's unreasonable to believe that it would have a QoS policy for peer C. Not sure we need to do anything about this, but we'd be happy for people to tell us differently.

Yoav