Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-11

[Keyur Patel <[e-mail]>]

Hi Linda,

Apologies for the delayed response. Responses are inline. #Keyur

From: Linda Dunbar <[e-mail]>
Date: Thursday, March 28, 2019 at 6:52 AM
To: idr wg <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-11
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent-Date: Thursday, March 28, 2019 at 6:52 AM

Just want to reiterate my questions and issues I raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-11, to make it easier for the authors to address them in the next revision (I have sent the questions multiple times on the IDR mailing list, but no one responded):


  1.  When a client route can egress multiple egress ports (each with different IP addresses), does the Tunnel-Encap allow multiple “Remote-endpoint” SubTLV to be attached one UPDATE?

#Keyur: Yes. Section 5 of the draft version 12 has a following  text:

<snip>
A Tunnel Encapsulation attribute may contain several TLVs that all
   specify the same tunnel type.  Each TLV should be considered as
   specifying a different tunnel.  Two tunnels of the same type may have
   different Remote Endpoint sub-TLVs, different Encapsulation sub-TLVs,
   etc.  Choosing between two such tunnels is a matter of local policy.
</snip>



  1.  Section 3.1 Page 10: The last paragraph states that if “Remote-Endpoint sub-TLV contains address is valid but not reachable, and the containing TLV is NOT be malformed ..”. Why a address not reachable is considered as “Not Malformed”?

#Keyur: That is because the Remote-Endpoint could become reachable at the later time. Making it malformed would mean that the Remote-Endpoint has to be dropped upon a receipt of the update message (and could never be used).



  1.  In RFC5512, the BGP speaker indicates the originating Interface address in the NLRI (section 3):

[cid:image001.png@01D4E575.D3039A30]

draft-ietf-idr-tunnel-encaps-11  no longer has the BGP speaker originating the update. Is it intended? If Yes, does it mean that it allows a third party (which could be malicious entity) to inject routes on behalf of a legitimate router (but RFC5512 doesn’t)?  Why add this scenario? How to address the security threats introduced? If it is a conscious decision, should have some text to explain why and how to mitigate the security threats introduced.

#Keyur: Section 13 of the draft version 12 describes Security Considerations that should address your security questions. The option is to provide flexibility.

Regards,
Keyur



Thanks, Linda Dunbar