Re: [IPsec] New draft for addressing ADVPN (draft-sathyanarayan-ipsecme-advpn-00)

[Yoav Nir <[e-mail]>]

On Jul 7, 2013, at 5:51 AM, Paul Hoffman <[e-mail]> wrote:

> On Jul 6, 2013, at 7:46 PM, Praveen Sathyanarayan <[e-mail]> wrote:
> 
>> 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. 
> 
> 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?

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