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

[Vishwas Manral <[e-mail]>]

Hi Lou,

Thanks for your close reading of the document. I am attaching the changed
document. Please let me know if it looks good.

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

I have reordered the sentences.

>
> 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...")
>
I changed the "can" to a SHOULD for the second part. The idea is no changes
should happen in configuration and our current solution allows that for
most cases (hence SHOULD).

>
> 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".
>
> Updated it. I agree we can separate out the terms NAT gateway/ Gateway,
though for most parts it may be the same device. Prepend NAT to change it
to NAT gateway, as just replacing it with NAT made the sentence out of
place.


> 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.)
>
> Do you have any reference and suggested text for this? I have not seen the
same in our customer cases.

Thanks,
Vishwas