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

From: Lou Berger <[email-masked]>
Date: Thu, 15 Nov 2012 17:44:15 -0500

Authors,

As I mentioned in last week's meeting, I have some comments on this
document from the routing perspective.  I don't think these are major,
but I still think they should be addressed.

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!

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.

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

   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 also have a few more minor comments:

- 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

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 15 Nov 2012 16:14:08 -0800

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:

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

> 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

    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.

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

> If you want, you can make the "SHOULD" a "MUST", and "support" could be
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. I see the 2 working in different layers, and
interacting only in edge gateways where both solutions have an edge.

> I also have a few more minor comments:
I am ok with the minor suggestions you have.

Thanks,
Vishwas

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 15 Nov 2012 19:46:19 -0500

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

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

> more context you can provide for the same.

4.2 = 4.1

> I do not want to go ahead into details of what other routing solutions
> it should support.
> 
> 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
>     [email-masked] <mailto:[email-masked]>

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 16 Nov 2012 09:49:36 -0800

Hi Lou,

Thanks for the quick reply. Just a few comments prefixed with a "VM>":

> OK got it.

> >        with minimal, or no, configuration impact.
VM> Ok will specifically specify tunnels and routing protocols.

> (To explicitly include this case.)  If the WG wants this case excluded,
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. Do you see a reason to explicitly mention L3VPN in this case?

Thanks,
Vishwas

---

From: Lou Berger <[email-masked]>
Date: Fri, 16 Nov 2012 13:16:24 -0500

Vishwas,

Please see below.

> VM> Ok will specifically specify tunnels and routing protocols.

Great.

> 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
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 16 Nov 2012 10:34:00 -0800

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

---

From: Lou Berger <[email-masked]>
Date: Fri, 16 Nov 2012 13:44:57 -0500

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:
> 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 <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Vishwas,
> 
>     Please see below.
> 
>     >     >     If you want, you can make the "SHOULD" a "MUST", and
>     "support"
>     >     could be
>     >     >     "be compatible with".
>     >     >
>     >     > With that said I am not sure what you mean by having BGP
>     MPLS VPN
>     >     in an
>     >     > layers, and interacting only in edge gateways where both
>     solutions
>     >     have
>     >     > an edge.
>     >
>     >     >     dynamic dns to handle this issues (and is currently
>     supported
>     >     by some
>     >     >     vendors.)
>     >     >
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 16 Nov 2012 10:48:41 -0800

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 <[email-masked]> 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

---

From: Lou Berger <[email-masked]>
Date: Fri, 16 Nov 2012 14:00:00 -0500

Vishwas,

On 11/16/2012 1:48 PM, Vishwas Manral wrote:
> Hi Lou,
> 
> Got it. Can you suggest some text for this? I will try to incorporate
> the same into the document.

Assuming you don't like my prior attempt:
X.  The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364].

How about something like:
X. The solution MUST support Provider Edge (PE) based VPNs.

Note that this phrasing doesn't indicate a specific solutions which is
why I now suggest "MUST" vs "SHOULD".

Lou

> 
> Thanks,
> Vishwas
> 
> On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger <[email-masked]
>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Vishwas,
>     >
>     >     Please see below.
>     >
>     >     >     > the IPsec tunnels and the solution should make an
>     effort to
>     >     allow for
>     >     >     >    Routing using the tunnels can work seamlessly
>     without any
>     >     >     updates to
>     >     >     >        routing protocols operating over spoke-to-spoke
>     IPsec
>     >     Tunnels
>     >     >     >        X.  The solution SHOULD support BGP/MPLS IP
>     VPNs, see
>     >     >     [RFC4364].
>     >     >     >
>     >     >     > I do not want to go ahead into details of what other
>     routing
>     >     solutions
>     >     >     > it should support.
>     >     >     >
>     >     >     (To explicitly include this case.)  If the WG wants this
>     case
>     >     excluded,
>     >     >     that's fine too.
>     >     >
>     >     > my view the L3VPN and the IPsec VPN are 2 different layers
>     in the
>     >     stack
>     a BGP VPN
>     >     >     >     - In section 2.1, you introduce the term "NAT
>     gateway" and
>     >     >     then later
>     >     >     >     using the term "NAT" and thereby not introduce
>     possible
>     >     confusion
>     >     >     >     between the gateway term defined in section 1.1
>     and "NAT
>     >     >     gateways".
>     >     >     >
>     <mailto:[email-masked] <mailto:[email-masked]>>>>

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 16 Nov 2012 11:10:54 -0800

Thanks Lou,

Let me heard back from the WG on this, if they have any opinion. If not we
can go ahead with your suggestion.

-Vishwas

On Fri, Nov 16, 2012 at 11:00 AM, Lou Berger <[email-masked]> wrote:

> >     >     >     > We can add something in the lines of additional
> protocols
> >     >     are run over
> >     >     >     > additional protocols like OSPF to be run optimally
> without
> >     >     too many
> >     >     >     >    the higher level application configuration i.e.
>  OSPF
> >     >     >     configuration.
> >     >     >     >
> >     >     >     > ADVPN scenario. BGP MPLS VPN is a provider provisioned
> VPN
> >     >     solution,
> >     >     >     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."
> >     >     > over GRE tunnels/ L2TP tunnels, which can themselves use
> IPsec.
> >     >     Again in
> >     >     >     >     static configuration impossible.  This doesn't
> reflect
> >     >     the use of

---

From: Lou Berger <[email-masked]>
Date: Fri, 16 Nov 2012 14:16:50 -0500

Sounds like a plan.  Thanks for the quick response(s).

Lou

On 11/16/2012 2:10 PM, Vishwas Manral wrote:
> Thanks Lou,
> 
> Let me heard back from the WG on this, if they have any opinion. If not
> we can go ahead with your suggestion.
> 
> -Vishwas
> 
> On Fri, Nov 16, 2012 at 11:00 AM, Lou Berger <[email-masked]
>     >             Sure, but it's the BGP information that indicates what
>     IPsec
>     >     tunnels
>     >     > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger
>     <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>     >     >
>     >     >     Vishwas,
>     >     >
>     >     >     Please see below.
>     >     >
>     >     >     >     > additional protocols like OSPF to be run
>     optimally without
>     >     >     too many
>     >     >     >     >    the higher level application configuration
>     i.e.  OSPF
>     >     >     >     configuration.
>     >     >     >     >
>     >     >     >     > ADVPN scenario. BGP MPLS VPN is a provider
>     provisioned VPN
>     >     >     solution,
>     >     >     >     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."
>     >     >     > understand your concern better I may feel otherwise).
>     L3VPN
>     >     can work
>     >     >     > over GRE tunnels/ L2TP tunnels, which can themselves
>     use IPsec.
>     >     >     Again in
>     >     >     be able to use dynamic PE to PE IPsec tunnels.  Does
>     this fit
>     >     your "2
>     >     >     >     >     - In sections 2.2, and Section 3.2 you say
>     dynamic
>     >     >     addresses makes
>     >     >     >     >     static configuration impossible.  This
>     doesn't reflect
>     >     >     the use of
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 24 Nov 2012 09:21:09 -0800

Hi WG-participants,

As its been a week and I have not heard any objections, I will update this
requirement and post the draft across.

Thanks,
Vishwas
On Fri, Nov 16, 2012 at 11:10 AM, Vishwas Manral <[email-masked]>wrote:

>> >     >     >     2 (intro) and 2.2, I saw no such restriction.  So I
>> think
>> >     >     section 2.2