Re: [Rift] Jim raised the concern about TTL issue at IETF118 and require to add some text to rift-applicability draft

[[e-mail]]

Hi,
Happy holidays!
Your comments are resolved, and a new version was just uploaded.
https://mailarchive.ietf.org/arch/msg/rift/zPJ3XaPD7tYWX_q2wBUmyRn37r4/

Best Wishes,


Yuehua Wei






Original


From: AlvaroRetana <[e-mail]>
To: [e-mail] <[e-mail]>;Alvaro Retana <[e-mail]>;魏月华00019655;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;James Guichard <[e-mail]>;
Date: 2023年12月19日 02:59
Subject: Re: Jim raised the concern about TTL issue at IETF118 and require to add some text to  rift-applicability draft


Works for me.

 
Thanks!

 
On December 16, 2023 at 1:48:42 AM, [e-mail] ([e-mail]) wrote:



hi，Tony and Alvaro,
Based on your comments, the text is amended as following:
-----
5.17 TTL/HopLimit of 1 vs. 255 on LIEs/TIEs
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in RIFT.
LIEs/TIEs MUST be sent with an IPv4 Time to Live (TTL) or an IPv6 Hop Limit (HL) of either 1 or 255 to prevent RIFT information reaching beyond a single L3 next-hop in the fabric. LIEs/TIEs arriving with IPv4 Time to Live (TTL) or an IPv6 Hop Limit (HL) different than 1 or 255 MUST be ignored.
RIFT explicitly requires the use of a TTL/HL value of 1 *or* 255 when sending/receiving LIEs and TIEs so that implementors have a choice between the two.  TTL (or HL) = 1 protects against the information disseminating more than 1 hop in the fabric and should be the default unless configured otherwise.  TTL (or HL) = 255 can lead RIFT TIE packet propagation to more than one hop  (multicast address is already local subnetwork range) in case of implementation problems but does protect against a remote attack as well,  and the receiving remote router will ignore such TIE packet unless the remote router is exactly 254 hops away and accepts only TTL=1.
[RFC5082] defines a Generalized TTL Security Mechanism (GTSM). The GTSM is applicable to LIEs/TIEs implementations that use a TTL or HL of 255. It provides a defense from infrastructure attacks based on forged protocol packets from outside the fabric.
For implementations that use a TTL or HL of 1, there are some security threats that are left open.  For example, it is relatively easy to spoof a packet remotely so that it has a TTL of 1 within the fabric.  Please see the Security Considerations in [RFC5082].
 
I appreciate your comments.
 


Best Regards,
Yuehua Wei

 



 







From: AntoniPrzygienda <[e-mail]>
To: 魏月华00019655;Jordan Head <[e-mail]>;[e-mail] <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;Jeffrey (Zhaohui) Zhang <[e-mail]>;
Date: 2023年12月16日 04:19
Subject: Re: Jim raised the concern about TTL issue at IETF118 and require to add some text to  rift-applicability draft



okey, 
 

I fully support adding this to applicability draft with amedments below  

here the comment as to correctness 

TTL=1 protects against the information disseminating more than 1 hop in the fabric and should be the default unless configured otherwise

TTL=255 can lead to more than one hop RIFT TIE packet propagation (multicast address is already local subnetwork range) in case of implementation problems but does protect against a remote attack as well and the receiving remote router will ignore such unless the remote router is exactly 254 hops away and accepts only TTL=1. 

the ‘MUST be ignored’ should be amended (unless explicitly configured otherwise). Just like in case of MTU mismatch a knob is always necessary due to some deployment corner cases 


 
AFAIS this can be still discussed, we’re not RFC yet and implementations can be knob’ed to accept anyting and send anything (just like the ‘OSPF security check’ knob so common today … 
 

tony 


 
 



 

 
Juniper Business Use Only
 

From: [e-mail] <[e-mail]>
 Date: Friday, 15 December 2023 at 04:31
 To: Jordan Head <[e-mail]>, [e-mail] <[e-mail]>
 Cc: Antoni Przygienda <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Jeffrey (Zhaohui) Zhang <[e-mail]>
 Subject: Jim raised the concern about TTL issue at IETF118 and require to add some text to  rift-applicability draft 
 


[External Email. Be cautious of content]
 
hi Jordan and Jim,
Jim raised the concern about TTL issue at IETF118 (https://datatraker.ietf.org/doc/minutes-118-rift/), and require to add some text to the rift-applicability draft to wrap up the draft with base spec together.
The following text is proposed to add to new version of  draft-ietf-rift-applicability as a section of "5.  Operational Considerations", please review and comment, thanks!
 
5.17 TTL/HopLimit of 1 vs. 255 on LIEs/TIEs
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in RIFT.
LIEs/TIEs MUST be sent with an IPv4 Time to Live (TTL) or an IPv6 Hop Limit (HL) of either 1 or 255 to prevent RIFT information reaching beyond a single L3 next-hop in the fabric. LIEs/TIEs arriving with IPv4 Time to Live (TTL) or an IPv6 Hop Limit (HL) different than 1 or 255 MUST be ignored.
RIFT explicitly requires the use of a TTL/HL value of 1 *or* 255 when sending/receiving LIEs and TIEs so that implementors have a choice between the two.
[RFC5082] defines a Generalized TTL Security Mechanism (GTSM). The GTSM is applicable to LIEs/TIEs implementations that use a TTL or HL of 255. It provides a defense from infrastructure attacks based on forged protocol packets from outside the fabric.
For implementations that use a TTL or HL of 1, there are some security threats that are left open.  For example, it is relatively easy to spoof a packet remotely so that it has a TTL of 1 within the fabric.  Please see the Security Considerations in [RFC5082].
 
 

Best Regards,
Yuehua Wei






Non-Junipe