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 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?
>
> I am a bit confused here.

You said
" 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 performed the changes you asked for. For the second part I have told you
the reason below. What am I missing?

>
> >
> >
> >     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?
>
> VM> I think this is an important requirement. A tunnel should be able to
provide an interface by which when tunnel IP parameters change we do not
have to change any configuration for higher application like Routing. I had
earlier mentioned in more generic terms earlier but changed to the terms
provided based on feedback from the list.

The entire idea is the with scale configuration needs to be reduced and
that needs to happen across layers, so every layer needs to provide the
service. Let me know what it is I am unable to convey.

>
>
> 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.
>
I am not sure how to 2 sentences mean the same thing, with DDNS inputs you
have given. Are you saying keep the old text as well as add the new text.

>
> 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.
>
>  Same comment as above.

Thanks,
Vishwas

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