Re: [IPsec] My comments to the draft-ietf-ipsecme-ad-vpn-problem-03.txt

[Vishwas Manral <[e-mail]>]

Hi Tero,

I am attaching the draft with your comment incorporated.

Regarding points 6 & 7 below I think there is some confusion. A spoke in my
view can be both an endpoint and a gateway. So within a ADVPN domain the
concept of connections to a spoke gateways from end points are not in the
perview at all. Do let me know if that makes sense?

If you approve this I will post the draft across.

Thanks,
Vishwas

On Fri, Dec 21, 2012 at 1:50 AM, Tero Kivinen <[e-mail]> wrote:

> I now read the lastest version. The terminology is much clearer now,
> and the document is much easier to read. I still see that not all of
> my comments in previous versions have been added to the document (some
> even from my 2012-03-14 email
> http://www.ietf.org/mail-archive/web/ipsec/current/msg07558.html, i.e
> the changes to section 3.1, 3.2 and 3.3).
>
> I am now going through my comments from 2012-09-10 email
> http://www.ietf.org/mail-archive/web/ipsec/current/msg07910.html and
> see which still apply).
>
> ----------------------------------------------------------------------
>
> Now that we have new terminology, it would be nice to have all terms
> defined in the terminology to use capital letter, so it would be clear
> that Hub/Gateway/Spoke/Endpoint etc has special meaning...
>
> ----------------------------------------------------------------------
>
> > 4.1.  Gateway and Endpoint Requirements
> > ...
> >    2.  Gateways and endpoints MUST allow IPsec Tunnels to be setup
> >    without any configuration changes, even when peer addresses get
> >    updated every time the device comes up.  This implies that SPD
> >    entries or other configuration based on peer IP address will need to
> >    be automatically updated, avoided, or handled in some manner to avoid
> >    a need to manually update policy whenever an address changes.
>
> In this I was trying to ask whether this is supposed to for existing
> already configured Gateways and endpoints, and as now the 1 has been
> changed to include gateway or endpoints addition/removal/changes, it
> is quite clear this only covers the normal operational use, i.e. when
> the gateways and endpoints are already configured. Perhaps changing it
> something like
>
>    2. Existing member Gateways and endpoints of the ADVPN 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. This implies that SPD entries or
>    other configuration based on peer IP address will need to be
>    automatically updated, avoided, or handled in some manner to avoid
>    a need to manually update policy whenever an address changes.
>
> to make it clear that we are not talking about the initial
> configuration but the actual normal use case of 2 peers which are
> already part of the ADVPN.
>
> BTW, perhaps we should add "ADVPN Peer" to the terminology and say it
> is any member (gateway, endpoint, hub or spoke) of the ADVPN and use
> "other ADVPN peers" above instead of "other members of the ADVPN".
>
> Or see if there is any other uses for peer than exactly that, and then
> define "Peer" to be same as ADVPN Peer...
>
> ----------------------------------------------------------------------
>
> >   4.  In the full mesh and dynamic full mesh topology, Spokes MUST
> >   allow for direct communication with other spoke gateways and
> >   endpoints.  In the star topology mode, direct communication between
> >   spokes MUST be disallowed.
>
> I have question here, why are we defining things for strict star
> topology mode, as the 2.2 says star topology is not good, and we need
> to have spoke to spoke communications. So 2.2 does NOT justify the
> last sentence in this requirement that forbids spoke to spoke
> communications for star topology mode. What is the justification for
> it?
>
> If we are not defining things for star topology we should not put any
> restrictions to it either. In my March email I pointed out that star
> topology is sometimes used for policy reasons, but that addition never
> made to the document. Those policy reasons might be one reason why
> some setups would still use star topology even with ADVPN, but I would
> expect it to be more like half star half mesh setup, where some
> traffic goes through star and some traffic bypasses it, so even there
> the last sentence does not work out.
>
> ----------------------------------------------------------------------
>
> >   5.  One spoke MUST NOT be able to impersonate another spoke.
>
> Note, that this does not say anything about the Hubs or Endpoints. For
> Endpoints I think there should be same requirement, i.e. one Endpoint
> MUST NOT be able to impersonate another Endpoint or Gateway.
>
> Btw, I think it would also be unacceptable for Spoke to impersonate of
> being Hub, so the "another Spoke" should be changed to "any other
> Gateway".
>
> Note, also that Spokes and Hubs quite often can impersonate Endpoints,
> as Endpoints might use weak form authentication (shared secrets), and
> the Spokes have access to them. Also when using temporary credentials
> given by Spokes/Hubs etc to the Endpoints for Point-to-Point
> communication between two Endpoints the entity who gave those out
> might be able to impersonate Endpoints (unless the temporary
> credentials is in form of certificate signed by some CA).
>
> When I pointed this out last time, I got answer that this document is
> trying to impose the "typical enterprice connectivity scenario" here,
> but I think we should think these requirements, not rely on some
> unspoken enterprice connectivity scenario. Especially as it do limit
> our options and will affect our threat model.
>
> So I would like to see expictly whether Hubs should be able to
> impersonate other Gateways / Endpoints and same for Endpoints.
>
> Also last time the comment was that with this "typical enterprice
> connectivity scenario" spoke to hub connections are static, but now we
> have requirement 7 which says that gateway might handoff sessions to
> another gateway. Gateway includes hubs, so hub can handoff spokes to
> another hub if he feels like. If this was not intended, then 7 should
> be changed so it says "Spokes SHOULD allow for easy handoff of a
> session to another Spoke, ...".
>
> Also as this connectivity scenario is not documented anywhere, so if
> it is wanted, we should add text for it, i.e. most likely change the
> Hub and Spoke definitions to say that connections between Hubs and
> Spokes are mostly static.
>
> ----------------------------------------------------------------------
>
> >   6.  Gateways SHOULD allow for seamless handoff of sessions in case
> >   endpoints are roaming, even if they cross policy boundaries.  This
> >   would mean the data traffic is minimally affected even as the handoff
> >   happens.  External factors like firewall, NAT box will not be
> >   considered part of this solution.
> >
> >   This requirement is driven by use case 2.1.  Today's endpoints are
> >   mobile and transition often between different networks (from 4G to
> >   WiFi and among various WiFi networks).
>
> This is still unclear. Last time I proposed two options, and I was
> said that both of them might be correct, but neither one of them are
> what is really said above.
>
> As the 2.1 is Endpoint-to-Endpoint use case, I assume this is supposed
> to say that "Spokes SHOULD allow for seamless handoff of sessions to
> Point-to-Point communication mode between Endpoints that used to be
> connected to Spoke, in case ...".
>
> I.e. This does not cover the Endpoint moving from one Spoke to
> another, but two Endpoints talking through Spokes moving to the
> Point-to-Point mode, I think the Endpoint moving from one Spoke to
> another Spoke is covered by requirement 7.
>
> Right?
>
> ----------------------------------------------------------------------
>
> >   7.  Gateways SHOULD allow for easy handoff of a session to another
> >   gateway, to optimize latency, bandwidth, load balancing,
> >   availability, or other factors, based on policy.
> >
> >   This requirement is driven by use case 2.3.
>
> And as 2.3 is Endpoint-to-Gateway, I assume this is the case where
> Spoke gives one Endpoint to another Spoke..., i.e. "Spokes SHOULD
> allow for easy handoff of a Endpoint to another Spoke, ...".
>
> Am I correct here?
>
> And if we assume Hub<->Spoke connection is mostly static we do not
> allow Hubs to handoff Spokes to another Hubs (if we do want to say
> that, then we can use the "Gateways" above).
>
> These 6 and 7 use term "session" which is not very well defined. There
> are multiple possible meanings for it, and I think it would be good
> idea to try to define which one of them is meant.
> --
> [e-mail]
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>