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

[Lou Berger <[e-mail]>]

Vishwas,
	Thanks for the quick response.  Please see below.

On 11/15/2012 7:14 PM, Vishwas Manral wrote:
> Hi Lou,
> 
> Thanks a lot for your detailed comments. I have just started to change
> the document today, based on feedback I got on the list, so your
> comments come at a good time. My answers are inline:
> 
>     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!
> 
> Yes, the idea is an IPsec gateway will have Routing functionality too.
> Now whether its a tunnel gateway with routing embedded or the otehr way
> around is debatable. I also agree Routing is a big part of the
> functionality to be optimized, though I would consider it a different
> sub-part of the solution.
> 
> 
>     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.
> 
> 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.
> 
> Infact we have a requirement to the effect in section 4.1

yes, this is what I referred to as 4.2 below, and suggested some
replacement text...

> 
>     Gateways MUST allow tunnel binding, such that applications like
>    Routing using the tunnels can work seamlessly without any updates to
>    the higher level application configuration i.e.  OSPF configuration.
> 
> 
> 
>  
> 
>     - 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)
> 
> I cannot find Section 4.2 in the document 
> http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-00 is there
> more context you can provide for the same.

4.2 = 4.1

>  
> 
>        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 do not want to go ahead into details of what other routing solutions
> it should support.
> 
> With that said I am not sure what you mean by having BGP MPLS VPN in an
> ADVPN scenario. BGP MPLS VPN is a provider provisioned VPN solution,
> this is a customer provisioned one. 

Ahh, interesting point.  When I read the document I was looking to see
if it was scoped purely to CE/customer based solutions.  Reading section
2 (intro) and 2.2, I saw no such restriction.  So I think section 2.2
should be explicit on this point either way. Which is why I proposed the
text "There is also the case when L3VPNs operate over IPsec Tunnels."
(To explicitly include this case.)  If the WG wants this case excluded,
that's fine too.

> I see the 2 working in different
> layers, and interacting only in edge gateways where both solutions have
> an edge.

Sure, but the problem exists for both.

Thanks,
Lou
> 
> 
>     I also have a few more minor comments:
> 
> I am ok with the minor suggestions you have.
> 
> Thanks,
> Vishwas
>  
> 
> 
>     - 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
>     _______________________________________________
>     IPsec mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/ipsec
> 
> 
>