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

Lou Berger <lberger@labn.net> Tue, 04 December 2012 17:20 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C69421F8C72 for <ipsec@ietfa.amsl.com>; Tue, 4 Dec 2012 09:20:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.831
X-Spam-Level:
X-Spam-Status: No, score=-99.831 tagged_above=-999 required=5 tests=[AWL=1.234, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNL3whQ7H4Rw for <ipsec@ietfa.amsl.com>; Tue, 4 Dec 2012 09:20:49 -0800 (PST)
Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 00FDE21F8C6D for <ipsec@ietf.org>; Tue, 4 Dec 2012 09:20:48 -0800 (PST)
Received: (qmail 27946 invoked by uid 0); 4 Dec 2012 17:20:27 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 4 Dec 2012 17:20:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=SzAGtb0L/99Z8SKBw4ZJX+i9t3qdIPb9wXBvyflmrGE=; b=AArmRVCKE8ozCXs6ixG0ZOMsYs/RqaO84vZm4OnJHq0fmVwXbtC+YPUHg+fAV5hm6dhdHvOBsq9Odb9pZ8jysVZJolo/xHd/9BX4bneM+DA4por3UBH1BmEKwhAEEttt;
Received: from box313.bluehost.com ([69.89.31.113]:57638 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1TfwAU-00075B-Ib; Tue, 04 Dec 2012 10:20:26 -0700
Message-ID: <50BE30D9.4030903@labn.net>
Date: Tue, 04 Dec 2012 12:20:25 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Vishwas Manral <vishwas.ietf@gmail.com>
References: <50A5703F.4070305@labn.net> <CAOyVPHTWhv8=sP6kYkZmOEsjMsdr72P8fe=7w5XY0Hd_wP_9=w@mail.gmail.com> <50A58CDB.30402@labn.net> <CAOyVPHQ+n83DaVv6Q9Z0kvi0MyYrhPbB=L6ju4fwjTyRK1P22Q@mail.gmail.com> <50A682F8.9080907@labn.net> <CAOyVPHSvWhgaYm2s_8_37VuaR1e_5tiJai+04AKzm3HXkNwESg@mail.gmail.com> <50A689A9.1090803@labn.net> <CAOyVPHR1euA9TRnAp7V+OKjRkPARYYvQ+C0HnA70y-122sy9ZQ@mail.gmail.com> <50A68D30.2040203@labn.net> <CAOyVPHR4OVNuvMU-UxZAJUoKFugCWwUQq0dSRo-7gY=Y886LoQ@mail.gmail.com> <CAOyVPHRopwvE5U3ZF7kDxNe59OgTk7ydoFG6iqvZdOFUCvaGyA@mail.gmail.com>
In-Reply-To: <CAOyVPHRopwvE5U3ZF7kDxNe59OgTk7ydoFG6iqvZdOFUCvaGyA@mail.gmail.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2012 17:20:50 -0000

Hi Vishwas,
	Was it your intent to  fully incorporated the changes we discussed into
the -01 rev?   If so, I think some were missed (and I can send which in
a separate message.)

Thanks,
Lou

On 11/24/2012 12:21 PM, Vishwas Manral wrote:
> 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 <vishwas.ietf@gmail.com
> <mailto:vishwas.ietf@gmail.com>> 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 <lberger@labn.net
>     <mailto:lberger@labn.net>> wrote:
> 
>         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 <lberger@labn.net
>         <mailto:lberger@labn.net>
>         > <mailto:lberger@labn.net <mailto:lberger@labn.net>>> 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
>         <lberger@labn.net <mailto:lberger@labn.net>
>         >     <mailto:lberger@labn.net <mailto:lberger@labn.net>>
>         >     > <mailto:lberger@labn.net <mailto:lberger@labn.net>
>         <mailto:lberger@labn.net <mailto:lberger@labn.net>>>> 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
>         >     >     >     >     IPsec@ietf.org <mailto:IPsec@ietf.org>
>         <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>
>         >     <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>
>         <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>>
>         >     >     <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>
>         <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>
>         >     <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>
>         <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>>>
>         >     >     <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>
>         <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>
>         >     <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>
>         <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>>
>         >     >     >     <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>
>         <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>
>         >     <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>
>         <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>>>>
>         >     >     >     >     https://www.ietf.org/mailman/listinfo/ipsec
>         >     >     >     >
>         >     >     >     >
>         >     >     >     >
>         >     >     >
>         >     >     >
>         >     >
>         >     >
>         >
>         >
> 
> 
> 
> 
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>