[IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

[Lou Berger <[e-mail]>]

Authors,

As I mentioned in last week's meeting, I have some comments on this
document from the routing perspective.  I don't think these are major,
but I still think they should be addressed.

In section 1.1, you define the term gateway.  I'm assuming that you are
using the term in the normal IPsec context, and that it includes IPsec
enabled routers.  Is this correct?  If not, the text should make this
clear, and you can ignore the rest of my mail!

Assuming such routers are within scope, there are some complicating
issues with IPsec enabled routers that I think should be called out.  I
don't think much text is needed to cover this case. I'm not sure the
best way to address these, but I have some suggestions to get the
conversation started (and yes, I expect that you'll edit the text):

- In section 2.2, I think mentioning something about the routing
implications is worthwhile. How about at the end of the section adding
something along the lines of :

    Additionally, the routing implications of gateway-to-gateway
    communication must be addressed.  In the simple case,
    selectors provide sufficient information for a gateway to
    forward traffic appropriately.  In other cases, additional
    tunneling (e.g., GRE) and routing (e.g., OSPF) protocols are
    run over IPsec tunnels, and the configuration impact on those
    protocols must be considered.  There is also the case when
    L3VPNs operate over IPsec Tunnels.

- In section 4.2, how about:
   (replacement text)
   3.  Gateways MUST allow for the operation of tunneling and
   routing protocols operating over spoke-to-spoke IPsec Tunnels
   with minimal, or no, configuration impact.

and (new text)

   X.  The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364].

If you want, you can make the "SHOULD" a "MUST", and "support" could be
"be compatible with".

I also have a few more minor comments:

- In section 2.1, you introduce the term "NAT gateway" and then later
use just "gateway" when I suspect you mean "NAT gateway".  I suggest
using the term "NAT" and thereby not introduce possible confusion
between the gateway term defined in section 1.1 and "NAT gateways".

- In section 2.2, s/occupies/requires

- In sections 2.2, and Section 3.2 you say dynamic addresses makes
static configuration impossible.  This doesn't reflect the use of
dynamic dns to handle this issues (and is currently supported by some
vendors.)

Let me know what you think,
Lou