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

[Vishwas Manral <[e-mail]>]

Hi Lou,

Got it. Can you suggest some text for this? I will try to incorporate the
same into the document.

Thanks,
Vishwas

On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger <[e-mail]> wrote:

> Vishwas,
>         Sure, but it's the BGP information that indicates what IPsec
> tunnels
> are needed / when the SAs get established...
>
> Again, I just asking for language that points to this use case, not
> implementation details.
>
> Thanks,
> Lou
>
> On 11/16/2012 1:34 PM, Vishwas Manral wrote:
> > Hi Lou,
> >
> >> I'm not sure I agree with this statement.  Let's say you have
> >> a BGP VPN that uses IPsec tunnels between the PEs (which
> >> was described in a couple of expired drafts and can be supported
> >> using RFC5566), and then wants to be able to use dynamic PE
> >> to PE IPsec tunnels.  Does this fit your "2 different layer"
> >> perspective?
> > IPsec with ADVPN secures the tunnel and creates the mesh underlay on
> > need basis/ or automatically. L3VPN creates the overlay, identifies the
> > tenant/ customer a packet belongs to and passes the packet on.
> >
> > Where do we see the need for tighter integration here? Is it allowing
> > the ability to create groups of ADVPN instances?
> >
> > Thanks,
> > Vishwas
> >
> > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Vishwas,
> >
> >     Please see below.
> >
> >     On 11/16/2012 12:49 PM, Vishwas Manral wrote:
> >     > Hi Lou,
> >     >
> >     > Thanks for the quick reply. Just a few comments prefixed with a
> "VM>":
> >     >
> >     >     >
> >     >     > 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...
> >     >
> >     > OK got it.
> >     >
> >     >     >
> >     >     >     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.
> >     >
> >     > VM> Ok will specifically specify tunnels and routing protocols.
> >     >
> >
> >     Great.
> >
> >     >
> >     >     >
> >     >     >
> >     >     >        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.
> >     >
> >     > VM> It is not scoped purely as a CE device scenario, and after
> seeing
> >     > your comment I see no reason to leave that out of scope (though if
> I
> >     > understand your concern better I may feel otherwise). L3VPN can
> work
> >     > over GRE tunnels/ L2TP tunnels, which can themselves use IPsec.
> >     Again in
> >     > my view the L3VPN and the IPsec VPN are 2 different layers in the
> >     stack
> >     > if they run on the same device.
> >
> >     I'm not sure I agree with this statement.  Let's say you have a BGP
> VPN
> >     that uses IPsec tunnels between the PEs (which was described in a
> couple
> >     of expired drafts and can be supported using RFC5566), and then
> wants to
> >     be able to use dynamic PE to PE IPsec tunnels.  Does this fit your "2
> >     different layer" perspective?
> >
> >     Either way, I think such usage should be explicitly in scope as it
> is a
> >     very different model / use case from CE-based IPsec VPNs.
> >
> >     > Do you see a reason to explicitly
> >     > mention L3VPN in this case?
> >
> >     I'm open to different ways to cover the above.
> >
> >     Much thanks,
> >     Lou
> >     >
> >     > Thanks,
> >     > Vishwas
> >     >
> >     >
> >     >
> >     >     > 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]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>
> >     <mailto:[e-mail] <mailto:[e-mail]>
> >     >     <mailto:[e-mail] <mailto:[e-mail]>>>
> >     >     >     https://www.ietf.org/mailman/listinfo/ipsec
> >     >     >
> >     >     >
> >     >     >
> >     >
> >     >
> >
> >
>