Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
Timo Teras <timo.teras@iki.fi> Thu, 06 February 2014 10:07 UTC
Return-Path: <timo.teras@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8141A035D for <ipsec@ietfa.amsl.com>; Thu, 6 Feb 2014 02:07:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od75yO0FHJ65 for <ipsec@ietfa.amsl.com>; Thu, 6 Feb 2014 02:07:07 -0800 (PST)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 983601A00B4 for <ipsec@ietf.org>; Thu, 6 Feb 2014 02:07:06 -0800 (PST)
Received: by mail-la0-f49.google.com with SMTP id y1so1250786lam.8 for <ipsec@ietf.org>; Thu, 06 Feb 2014 02:07:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=nYIce11pdAYv5KdLyuPixnXt3jLS527UknzrvP3G6bU=; b=FIgd/ZtQMya0ZzvUlMUSP83HCxGgff1kU5tL1M8+tVBw2zDSDRwnnCrzM80dq+7B3N Tt+1aC9xGI4emfsLl7diqLhdb96H+9ud75A/S3dIoa/6xy/2LwbOrYyUapTUCLTEaSfU ByWWz0IbmKchAUrMxlr9DkEFXrzML2p2T2eTAdjC1w5qhfJoXbSSiRTZWQCpXkMs0jfJ lCQcRbV0P7xs+FKTWH60izbEHCyg4AE4eF4fxa7Z7zTDmlk1ptmb5mEcgvrw5rSzSFLw hxQRu5UoM3jy0jPrn518tvLQghZvb5nfUNa9cgO2EE6Sc1nbpfgfcmJ35Xz92Gz5uhcU kElg==
X-Received: by 10.112.138.233 with SMTP id qt9mr1350737lbb.34.1391681224929; Thu, 06 Feb 2014 02:07:04 -0800 (PST)
Received: from vostro ([2001:1bc8:101:f402:21c:23ff:fefc:bf0b]) by mx.google.com with ESMTPSA id ri4sm488537lbb.6.2014.02.06.02.07.04 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2014 02:07:04 -0800 (PST)
Sender: Timo Teräs <timo.teras@gmail.com>
Date: Thu, 06 Feb 2014 12:07:38 +0200
From: Timo Teras <timo.teras@iki.fi>
To: Daniel Migault <mglt.ietf@gmail.com>
Message-ID: <20140206120738.06195c09@vostro>
In-Reply-To: <CADZyTkmaZL9=0_cuu4TYw0M_846TWONMcOWQyEYr24m4YOyGWQ@mail.gmail.com>
References: <7DC80D6C-3342-43C3-9407-E5D25CB5F5CD@cisco.com> <CF02A72F.6A65A%praveenys@juniper.net> <20140205135046.61c4f7a5@vostro> <CADZyTkmaZL9=0_cuu4TYw0M_846TWONMcOWQyEYr24m4YOyGWQ@mail.gmail.com>
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.20; i486-alpine-linux-uclibc)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: "<ipsec@ietf.org> WG" <ipsec@ietf.org>, "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>, Praveen Sathyanarayan <praveenys@juniper.net>
Subject: Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 06 Feb 2014 10:07:09 -0000
On Thu, 6 Feb 2014 09:20:08 +0100 Daniel Migault <mglt.ietf@gmail.com> wrote: > Thanks for the feed back. > > We are happy you provide requirements over "dynamically routing > subnets" as a MUST. ADVPN responds to the requirements listed in > RFC7018. If there is a requirement that does not match you opinion, > can you please point it out? > > Just to make it clear this 1 day time has never been mentioned in the > draft and is your assumption. The use of TTL does not impose a 1 day > and ADVPN can take advantage of the Redirect Mechanism or MOBIKE for > multihoming. As you can see the ADVPN solution can take advantage of > all previous and future featured designed for IKEv2. As you point out > the key characteristic of our design is its flexibility. It was Praveen's suggestion in the email I replied. My point was that having that sort of default TTL does not sound good. And to me it sounds like having very low TTL (in level of seconds or minutes) is too heavy to be used in practice. So the TTL mechanism does not really sound feasible to me. > RFC5685 is not limited to client-gateway, the second line of the > section 10 you pointed out says: [...] the mechanism can also be used > between any two IKEv2 peers. " So no additional specification are > required. You missed the next sentance: "However, the mechanism can also be used between any two IKEv2 peers. But this protocol is asymmetric, meaning that only the original responder can redirect the original initiator to another server." Spoke A established tunnel to spoke B. A is thus original initiator. But the routing change is on spoke B subnet. B cannot send Redirect according to the above. You'd need to specify additional mechanism for that, or re-specify the original one. I believe this restriction is due to security considerations for client-gateway type connectivity. > You mention load balancing may be an issue. Can you please specify the > issue you see? Could you specify how in practice I could implement one subnet to be load-balanced to spoke nodes? > One last point to clarify. it seems that you are trying to say ADVPN > misses some features provided by routing protocols. In fact ADVPN can > take advanatge of ALL of these features as ANY routing protocol can > run on the top of ADVPN. This was a MUST requirement of RFC5685. If > you see a scenrio that you think does not fit ADVPN, please document > it so we can address your specific issue. I thought the advantage was to _not_ run routing protocol. If running routing protocol is supported, can you please specify how a routing protocol is to be integrated with the IKE traffic exchange? Yes, it is possible, but non-trivial, thus I would like to see some specification mapping how to do that mapping. And like someone else asked, how is MPLS routed? Thanks, Timo
- [IPsec] clariciations for draft-sathyanarayan-ips… Frederic Detienne (fdetienn)
- Re: [IPsec] clariciations for draft-sathyanarayan… Frederic Detienne (fdetienn)
- Re: [IPsec] clariciations for draft-sathyanarayan… Praveen Sathyanarayan
- Re: [IPsec] clariciations for draft-sathyanarayan… Frederic Detienne (fdetienn)
- Re: [IPsec] clariciations for draft-sathyanarayan… Praveen Sathyanarayan
- Re: [IPsec] clariciations for draft-sathyanarayan… Frederic Detienne (fdetienn)
- [IPsec] Moving prefixes -- clariciations for draf… Frederic Detienne (fdetienn)
- Re: [IPsec] Moving prefixes -- clariciations for … Praveen Sathyanarayan
- Re: [IPsec] Moving prefixes -- clariciations for … Yoav Nir
- Re: [IPsec] clariciations for draft-sathyanarayan… Timo Teras
- Re: [IPsec] Moving prefixes -- clariciations for … Frederic Detienne (fdetienn)
- Re: [IPsec] Moving prefixes -- clariciations for … Frederic Detienne (fdetienn)
- Re: [IPsec] Moving prefixes -- clariciations for … Praveen Sathyanarayan
- Re: [IPsec] Moving prefixes -- clariciations for … Frederic Detienne (fdetienn)
- Re: [IPsec] Moving prefixes -- clariciations for … Praveen Sathyanarayan
- Re: [IPsec] Moving prefixes -- clariciations for … Frederic Detienne (fdetienn)
- Re: [IPsec] clariciations for draft-sathyanarayan… Daniel Migault
- Re: [IPsec] clariciations for draft-sathyanarayan… Timo Teras
- Re: [IPsec] Moving prefixes -- clariciations for … Praveen Sathyanarayan
- Re: [IPsec] clariciations for draft-sathyanarayan… Daniel Migault
- Re: [IPsec] clariciations for draft-sathyanarayan… Timo Teras