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

[Lou Berger <[e-mail]>]

Vishwas

On 12/4/2012 12:54 PM, Vishwas Manral wrote:
> Hi Lou,
> 
> Yes that's the intent. Please let me know what is it that we agreed to,
> that is not there in the draft.
> 
> Thanks,
> Vishwas

Here's what I think has been missed (plus one new comment):


On 11/15/2012 7:14 PM, Vishwas Manral wrote:
>     - 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.
>
> We can add something in the lines of additional protocols are run over
> the IPsec tunnels and the solution should make an effort to allow for
> additional protocols like OSPF to

Also in section 2.2, the text now says:

   The solution should work in cases where the endpoints are
   administrated by separate management domains, albeit, ones that have
   an existing trust relationship (for example two organisations who are
   collaborating on a project, they may wish to join their networks,
   whilst retaining independent control over configuration)It is for
   this purpose spoke-to-spoke tunnels are dynamically created and torn-
   down.  It is highly desirable that the solution works for the star,
   full mesh as well as dynamic full mesh topology.

This revision now reads that the primary reason for dynamic
spoke-to-spoke tunnels is separate management domains.  I somehow don't
think this was the intent.

In section 4.1 we had discussed replacement text for 3:
On 11/16/2012 12:49 PM, Vishwas Manral wrote:
>>On 11/15/2012 5:44 PM, Lou Berger wrote:
>>     - 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.
>
>VM> Ok will specifically specify tunnels and routing protocols.

You have the following alternate / revised text:
   3.  In many cases additional tunneling protocols (i.e.  GRE) or
   Routing protocols (i.e.  OSPF) are run over the IPsec tunnels.
   Gateways MUST allow for the operation of tunneling and Routing
   protocols operating over spoke-to-spoke IPsec Tunnels with minimal or
   no, configuration impact.  Routing using the tunnels can work
   seamlessly without any updates to the higher level application
   configuration i.e.  OSPF configuration, when the tunnel parameter
   changes.

I think this text is closer, but I think a few additional changes are
needed:
 - GRE and OSPF are examples, so "i.e." should be replaced with "e.g."
 - I think the final sentence is likely to be incorrect in many / most
   real world cases, so would drop the sentence (from "Routing using
   the tunnels can work...")

You also said you'd address the minor comments:
On 11/15/2012 5:44 PM, Lou Berger wrote:
> - 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".

and

> - 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.)

That's it.  Let me know what you think.

Much thanks,
Lou