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

[Tero Kivinen <[e-mail]>]

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]