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

[Eric C Rosen <[e-mail]>]

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.