Re: [IPsec] NUDGE: Reviewing the AD VPN drafts
"Frederic Detienne (fdetienn)" <fdetienn@cisco.com> Tue, 15 October 2013 16:57 UTC
Return-Path: <fdetienn@cisco.com>
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 0836B21E80C4 for <ipsec@ietfa.amsl.com>; Tue, 15 Oct 2013 09:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.399
X-Spam-Level:
X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9Y0X013a5Eb for <ipsec@ietfa.amsl.com>; Tue, 15 Oct 2013 09:57:22 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 05ACC21E8064 for <ipsec@ietf.org>; Tue, 15 Oct 2013 09:56:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7610; q=dns/txt; s=iport; t=1381856220; x=1383065820; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZhpZlWpMdlt2COx3Lgonn6s3LXiEwKDDamW7uf/Zlf0=; b=efBvPrcN3H6okYjCn02olE0Po6iSEKMqiv8qlwPdW54MyS4sNGccMB2D Vv/fCxGIBANBD5QiTMwrmQvaO4JB5Oe8wsK+yFmacMrkIi0tHj679Dw3s Ij6vQeFjEeYGLfY02YTvfIIiUoQJbDGUw6d3dpefABfc+fczxURYYLUls I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAHZzXVKtJXG+/2dsb2JhbABRCYMHOFLCKYEjFnSCJQEBAQMBAQEBZAcLBQsCAQgYCiQnCyUCBA4FCBOHZQYMvVgEjgiBDwIxB4MfgQYDqgaDJIIp
X-IronPort-AV: E=Sophos;i="4.93,500,1378857600"; d="scan'208";a="272409583"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 15 Oct 2013 16:56:59 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9FGuxGr028301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 16:56:59 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.176]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 11:56:58 -0500
From: "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>
To: Praveen Sathyanarayan <praveenys@juniper.net>
Thread-Topic: [IPsec] NUDGE: Reviewing the AD VPN drafts
Thread-Index: AQHOv4q3wJGMGhH1F0e56liwS8HiOZniE4+AgAfLtwCAAvxdAIAJef2AgAAOOgA=
Date: Tue, 15 Oct 2013 16:56:58 +0000
Message-ID: <1A87A395651F8F439A0C9D8FE20EB0F529F201A0@xmb-aln-x06.cisco.com>
References: <CE82B49C.1BE466%praveenys@juniper.net>
In-Reply-To: <CE82B49C.1BE466%praveenys@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.147.25.58]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <5BAA7C1103E74F4AA617EF3034630728@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>, Yoav Nir <ynir@checkpoint.com>, "Manish Kumar (manishkr)" <manishkr@cisco.com>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts
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, 15 Oct 2013 16:57:27 -0000
On 15 Oct 2013, at 18:06, Praveen Sathyanarayan <praveenys@juniper.net> wrote: > > Are there any other detail that are not part of this draft, that is > required for interoperating with existing DMVPN solution? I think the draft is exhaustive. > And, is there > any other feature that DMVPN supports today (and not required for > interoperability) that is not part of this draft? yes. Not sure how much more you want to know... regards, fred > Thanks, > Praveen > > > On 10/9/13 8:23 AM, "Frederic Detienne (fdetienn)" <fdetienn@cisco.com> > wrote: > > Hi Yoav, > > Thanks indeed for your comments! Please find additional [Fred] comments > inline. > > On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) <manishkr@cisco.com> > wrote: > >> Hi Yoav, >> >> Thanks for your comments. I would try adding clarity to some of these >> inline [Manish] to supplement what Mike said. >> >> Manish >> >> >> On 03/10/13 12:14 AM, "Yoav Nir" <ynir@checkpoint.com> wrote: >> >>> Hi >>> >>> I have read the DM-VPN draft. I would not call my reading a review, as >>> it >>> was quite superficial, but here's some thoughts: >>> >>> - I have to admit that I'm still having trouble wrapping my head around >>> some of the concepts. I understand domain-based and route-pased VPNs, as >>> well as IPsec and GRE tunnels. But I haven't thought of all the VPN >>> endpoints as actually being on the same network. In fact I always >>> thought >>> of VPN as an abstract concept or as a bunch of tunnels, not as a real >>> network. Having said that, I'm still trying to get used to the idea of >>> NHRP being used for discovery (and to the idea of NHRP itself). To my >>> mind a VPN is not an NBMA, but that does not mean an NBMA cannot serve >>> as >>> a good model for a VPN. >> >> [Manish]: What the applications running over the VPN see a VPN as (NBMA >> or >> otherwise), depends a lot on the services provided on the VPN and the >> draft doesn't preclude any possibilities that way. >> RFC 4301 already prescribes the arms and ammunitions needed to protect IP >> packets (when used in connection with GRE can be used to protect IP >> multicast as well as non-IP packets) over untrusted networks. Also, as >> appropriately noted in the requirements document, 4301 is silent on the >> way the IPSec databases are populated. So the problem is essentially of >> discovery and resolution. The discovery can be left to the routing >> protocol but the resolution would still be needed unless IGPs are >> multi-protocol, which they typically aren't. Even if they were, this >> would >> need a next-hop preservation which won't scale. So, essentially DMVPN >> picks up an appropriate address resolution protocol in NHRP which is >> enhanced to support both discovery and resolution. This is combined with >> GRE to make sure IP multicast and non-IP packets can be >> seamlessly(without >> changing any other layer/protocol) carried across the same tunnel and >> also >> to simplify the SPDs. > > [Fred] I would add that any forwarding database is good as long as it > meets the security requirements of the administrator. Routing tables are > used for the description but policy routing can be used tooĊ VRF's or > routing context are frequently used in practice as well. There are not > "pure" routing tables anymore. > > When it comes to L2 forwarding, the SPD today does not even fit anymore > and a total revamp would be necessary. > > By decoupling the output tunnel selection (or next-hop selection) from > the IPsec policy, we can take advantage of various forwarding policy > engines. > > >>> - I like how the process described in section 4.3 to 4.6 quickly >>> converges. If host a behind gateway A sends packets to host e behind >>> gateway E, and the packets travel though the tunnels AB, BC, CD, and DE, >>> then the discovery process might go through several hops, but the next >>> tunnel to be set up is AE. There is no case of setting up AC or AD. > >>> - Reading section 4.8, I see that within a single DM-VPN, there is a >>> natural progression from hub&spoke to mesh. There doesn't seem to be a >>> place for policy on whether a shortcut should or should not be >>> established. The resolution request is forwarded until the egress node. >>> So if, for example, you have two government agencies, each with its own >>> set of gateways, and two gateways (one belonging to each agency) have a >>> tunnel between them, there are two possible configurations: a single >>> DM-VPN, in which case they become a mesh, or two DM-VPNs, so that the >>> interdomain tunnel endpoints are egress nodes on their respective >>> DM-VPNs. Is there a way to implement a policy so that some shortcuts are >>> created between those other gateways? > >>> - Section 4.10 seems to be missing something. Suppose gateway A is >>> forwarding traffic to gateway B, and receives an Indirection >>> notification. So A sends a Resolution request. After a while, it >>> receives >>> a Resolution reply with TunS2 and PubS2 addresses. So now A should open >>> a >>> tunnel with TunS2 (right? I'm not clear about the fields). So section >>> 4.10 says that authentication between these two nodes will be done using >>> certificates. Considering that A has only just heard of TunS2's >>> existence, what fields are there going to be in the certificate that >>> will >>> let A know that this is indeed TunS2? While a single domain might have >>> some convention for this, AD-VPN is supposed to be good for multiple >>> administrative domains, so there should be some rule about this. > > > [Fred] We link the tunnel to an IKE profile. This IKE profile turns > contains the identity, identity filter, certificate and certificate filter > to send to and to accept from the remote peer. So we can create IKE > profiles for each DMVPN and send or accept specific certs. Typically, O or > OU fields are used. > > regards, > > fred > >>> - The same section hints at using certificate fields for filtering. This >>> sounds weird. Suppose two gateways learn of each other through the >>> resolution process. Now they try to connect, only to find out that the >>> certificate fields do not allow them to connect. So we've gone through >>> an >>> entire IKE handshake just to discover that policy prohibits forming this >>> tunnel? And because caches expire, the gateways will try again and again >>> to form this tunnel, all the time failing on authorization. >> >> [Manish]: Iff routing and NHRP policies(in general, all upper layer >> policies) allow the shortcut, IKE proceeds till Auth the first time and >> fails; this can be conveyed back to the upper layer (NHRP) with an >> appropriate error code, which sends a NACK resolution reply. The NACK >> serves to stop further resolutions either permanently or for an interval >> either configured or communicated by the peer. >> >>> >>> >>> Yoav >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > >
- [IPsec] NUDGE: Reviewing the AD VPN drafts Paul Hoffman
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Yoav Nir
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Michael Richardson
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Yoav Nir
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Yoav Nir
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Michael Richardson
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Michael Richardson
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Mike Sullenberger (mls)
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Manish Kumar (manishkr)
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Toby Mao
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Frederic Detienne (fdetienn)
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Praveen Sathyanarayan
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Frederic Detienne (fdetienn)
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Praveen Sathyanarayan
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Frederic Detienne (fdetienn)
- Re: [IPsec] NUDGE: Reviewing the AD VPN drafts Praveen Sathyanarayan