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

[Lou Berger <[e-mail]>]

considering the impact of deprecating an RFC on other RFCs seems to me
to be a reasonable thing to cover in the rfc doing the deprecating...


On 5/25/2017 2:10 PM, John E Drake wrote:
>
> 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.
>
>
>  
>
>  
>