IETF Logo Mail Archive

Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04

Lou Berger <lberger@labn.net> Thu, 25 May 2017 20:33 UTC

Return-Path: <lberger@labn.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE5D127871 for <idr@ietfa.amsl.com>; Thu, 25 May 2017 13:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 X4xO_mK-hVsL for <idr@ietfa.amsl.com>; Thu, 25 May 2017 13:33:27 -0700 (PDT)
Received: from gproxy8.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F66126C23 for <idr@ietf.org>; Thu, 25 May 2017 13:33:27 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id D883E1AB0D2 for <idr@ietf.org>; Thu, 25 May 2017 14:33:23 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id QkZL1v0022SSUrH01kZPqJ; Thu, 25 May 2017 14:33:23 -0600
X-Authority-Analysis: v=2.2 cv=VKStp5HX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=tJ8p9aeEuA8A:10 a=FfdZnV884f6bpAXlRDsA:9 a=s7XHToudHlygNAlb:21 a=Y1NeEWoyNrhDY_b5:21 a=pILNOxqGKmIA:10
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:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jewcdEyLeOG2fAKxzdR2f2PFyshCTJvcnrkn9gfdHIM=; b=VKhwYCJv7Wu8YKiVMYYIcsIGz1 ulqDjaIz4J+f3JG0Y3XGXn6ohA7C5rLoXgUQj2/toKq0TI3VhKje62nTwpt0pLQkHFp+99gN7Mpy2 NNAMyqpEAUg6DgBAqhCYvPvYp;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:50048 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1dDzRf-0005rR-Oy; Thu, 25 May 2017 14:33:19 -0600
To: Eric C Rosen <erosen@juniper.net>, "John G. Scudder" <jgs@juniper.net>
Cc: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net> <c735e3fe-1b0e-23a6-78bf-7e773e605a52@juniper.net> <9a3866bf-a561-df26-38e9-aff3cc4f2eeb@labn.net> <5ec5e327-5872-2754-4543-19e3b3465a1c@juniper.net> <17d44a51-b48b-1541-afb4-9b3878436b47@labn.net> <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net>
From: Lou Berger <lberger@labn.net>
Message-ID: <017c08ac-55f6-ab12-9b9c-54f03b570f03@labn.net>
Date: Thu, 25 May 2017 16:33:07 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <4466bd05-0362-b4be-ecf8-5881e228722d@juniper.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dDzRf-0005rR-Oy
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:50048
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/HC4owcerUBDjnQ1X0NpzPvqUvik>
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 May 2017 20:33:29 -0000


On 5/25/2017 1:54 PM, Eric C Rosen wrote:
> On 5/23/2017 12:10 PM, Lou Berger wrote:
>>> RFC 5566 assumes that the IPsec tunnel info and the authenticator
>>> sub-TLV is conveyed on an update of the encapsulation SAFI.   I'm not
>>> convinced that there are no addtional security issues to be considered
>>> if this information is carried on updates of other address families. 
>> I think the assumption is that the sub-TLVs are conveyed with the
>> attribute.  I don't see how changing the SAFI impacts this.
>
> I'm not saying that it does or does not, just that I'm not sure, and
> I'm not prepared now to defend a claim that the security aspects are
> not altered by this change.  So I'd rather see that addressed in a
> different document.
Well both of these are different statements than you made before.

So the way you'd prefer to resolve the 5566 issue is to leave it for the
future.  I can live with that, but think this should be made explicit
since 5512 is being deprecated.  How about something adding something
like the following to section  1

  RFC5566 uses the mechanisms defined in RFC5512, while this document
replaces RFC5512
  it does not address how the tunnel types defined in RFC5566 can be
used with SAFIs other
  than the Encapsulation SAFI. 

>
>>
>>> Also, note that in RFC 5512, the tunnels only extend to the BGP next
>>> hop, while in the tunnel-encaps draft the tunnel endpoints are not
>>> necessarily the BGP next hop.  This might also change some of the
>>> security properties.  I think this would have to be thought out fairly
>>> thoroughly, and I don't think that work's been done yet.
>> So leaving 5566 as is introduces this issue already (due to the
>> introduction of the remote endpoint sub-tlv).  If the we deprecate 5566
>> with this document, this can be trivially addressed by saying that the
>> endpoint Authenticator sub-tlv applies to the endpoint identified in the
>> Remote Endpoint Sub-TLV.
>
> I'm also not prepared to defend a claim that this is has no signficant
> impact to the security characteristics.
>
> Since the existing contents of the document do not depend upon
> anything in RFC 5566, I think obsoleting and replacing RFC 5566 is
> better done in a separate document .
>

That's fine assuming something like the above.

>>> I don't see how it could be correct for an implementation to always
>>> include an Encapsulation EC.  Sometimes you need to specify more than
>>> the tunnel type in order to construct the encapsulation properly.
>> It doesn't "hurt" to include it always and there is an implementation
>> that does this, so why not allow it?
>>
>
> It seems to me that it does hurt to include it.  If the intended
> tunnel endpoint is not the BGP next hop, or if the tunnel will not
> work unless the encapulation is prepared as specified within the
> attribute, then including an encapsulation EC for the same tunnel type
> provides false information.

Well we disagree.

Going back to your original text, if I read it right, sole use of the EC
was required in the case of a barebones "attribute".  Is this correct? 

If so, I certainly don't think it's reasonable to require use of EC in
some cases and attribute in others.  Allowing for both certainly has
maximal interop, but I think the required baseline should be the common
one, ie., tunnel attribute, not the special case; and EC can be added in
the barebones case.

>
>> The use of multiple tunnels between a pair of endpoints seems to make
>> sense, especially if the tunnels have different characteristics, and if
>> color can be used to map particular traffic flows to particular
>> tunnels.  This is something that has not changed from RFC 5512.  Note
>> also that even the Encapsulation EC allows multiple tunnels to be
>> specifiied (if they are of different types), since an EC attribute can
>> contain multiple instances of the same extended community.
>>
>>> I'm not arguing it that it's not a real use case, but rather that it can
>>> be solved using other existing, albeit more verbose, mechanisms.
>
> Allowing a choice of tunnels between a pair of endpoints should not
> require the origination of multiple routes with different NLRIs, or
> (even worse) the use of add-paths.  I don't really see the merit of
> this suggestion.
The point is simplification for an unused use case.  Is your position
based on theory or actual use?  As I mentioned before, if the latter I
withdraw this proposed simplification.  If the former, I think we should
simplify this case, just like we're eliminating Encap SAFI even though
it provides good theoretical benefits in advertisements.

>
>>> If you receive two routes, and
>>> want to aggregate them so that you only need to propagate one upstream,
>>> and the two routes have different tunnel-encaps attributes, you need
>>> some policy to decide what to do.  But that's true even if the
>>> tunnel-encaps attribute only specifies one tunnel.
>>
>> Sure, and the policy may be to merge the tlv lists.  This is the kind of
>> information I'm suggesting should be added.
>
> I think such policies will be very application-specific, and thus are
> out of scope of this document.  A draft proposing the use of the
> tunnel encaps attribute for a particular purpose might well have to
> deal with these policy issues.
>

Sounds like a future interop issue to me.  

Lou

v2.23.0 | Report a Bug | By Email