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

[John E Drake <[e-mail]>]

Hi,

Is it really the responsibility of  a RFC which obsoletes a another RFC to explain how every RFC referencing the obsoleted RFC is to be updated?  I think it's a much better idea to  update each of these RFCs individually.  So, as Eric suggests, I think an update to RFC 5566 is in order.

Yours Irrespectively,

John

From: Idr [mailto:[e-mail]] On Behalf Of Eric C Rosen
Sent: Thursday, May 25, 2017 1:54 PM
To: Lou Berger <[e-mail]>; John Scudder <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04

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.







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 .



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.



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.



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.