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

[Lou Berger <[e-mail]>]

Hi Vishwas,
	see below for response.

On 12/5/2012 12:54 PM, Vishwas Manral wrote:
> 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 be run optimally without too many 
>     > changes in configuration.
> 

I don't see any changes in 2.2 related to this (old) comment on routing
implications, am I missing something?

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

I think that works.

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

I think this is worse.  Now you're placing requirements on routing
protocols which IMO should not care if (or be aware of when) the tunnel
they are running on is IPsec or carried via IPsec.

What additional point are you trying to make in the following sentence?
   Routing using the tunnels SHOULD work
   seamlessly without any updates to the higher level application
   configuration i.e.  OSPF configuration, when the tunnel parameter
   changes.

Can the sentence just be dropped?

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

okay.  I probably just would had stayed with "NAT" and dropped
"gateway", but that's your call.

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

I've seen this supported on some firewall products in conjunction with
dynamic DNS.  I used one for a couple of years (the spoke used a dynamic
address + DDNS.)  I certainly deffer to the WG on if such usage should
be referenced in this document.  You are, after all, the experts on this
and I'm just an occasional user...

some possible text for section 2.2. could be:
OLD
   The gateways can themselves come up and down, getting different IP
   addresses in the process, making static configuration impossible.
NEW
   The solution should also address the case where gateways use dynamic
   IP addresses.

and section 3.2, perhaps something like:
OLD
   This solution however does not work when the spokes get dynamic IP
   address which the "hub gateways" cannot be configured with.
NEW
   This solution however is complicated by the case when the spokes
   use dynamic IP addresses and DNS with dynamic updates must be used.

Thanks,
Lou

> 
> Thanks,
> Vishwas
> 
> 
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>