[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: [IPsec] New draft for addressing ADVPN	(draft-sathyanarayan-ipsecme-advpn-00)
From:       Yoav Nir <ynir () checkpoint ! com>
Date:       2013-07-07 6:29:55
Message-ID: 209064D8-D0E5-4B8A-82D9-C2DA3B60E173 () checkpoint ! com
[Download RAW message or body]


On Jul 7, 2013, at 5:51 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> On Jul 6, 2013, at 7:46 PM, Praveen Sathyanarayan <praveenys@juniper.net>=
 wrote:
> =

>> We have "Appendix B Comparison Against ADVPN Requirements=B2. This secti=
on
>> 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 do=
esn'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 a=
ll the absolute requirements, as in #2: "ADVPN peers MUST allow IPsec Tunne=
ls to be setup with other members of the ADVPN without any configuration ch=
anges, 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 impr=
ovement is where the requirements are stated as "should be minimal" or "sho=
uld be simple". Specifically:

Requirement #1: "For any network topology ... gateways and endpoints SHOULD=
 minimize configuration changes when a new gateway or endpoint is added, re=
moved 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, an=
d to instruct E to send traffic to network c through gateway H. In a hub-an=
d-spoke configuration, that means that endpoint E has to be preconfigured w=
ith all of the addresses in the ADVPN. So if we add a gateway (with its ass=
ociated network) this new network has to be configured on all endpoints. Th=
is 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 sele=
ctor, 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 gatew=
ay sending the SHORTCUT messages (the suggester) has done IKE_AUTH with bot=
h spokes, and knows whether one or the other is behind NAT. If one is behin=
d NAT and the other is not, it can tell the one behind the NAT to be the in=
itiator. If both are behind NAT, it can and should avoid suggesting a short=
cut. 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 t=
hat is actively blocking them. We have considered adding NAT traversal mech=
anisms such as STUN, but we need to get more knowledge on the subject befor=
e we're ready to add this to our solution.


Requirement #15: per-peer QoS. Our protocol does not prevent peers from set=
ting up multiple tunnels for multiple QoS classes. However, the SHORTCUT no=
tification 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 abo=
ut this, but we'd be happy for people to tell us differently.

Yoav


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]