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

[[e-mail]]

Hi Jordan，
Thank you so much. 
I hope the draft would wrap up soon.

Best regard,
Yuehua Wei










Original



From: JordanHead <jhead=[e-mail]>
To: 魏月华00019655;Antoni Przygienda <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;Jeffrey (Zhaohui) Zhang <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年03月12日 21:02
Subject: Re: [Rift]  Jim raised the concern about TTL issue at IETF118 and require to add some text to  rift-applicability draft


_______________________________________________RIFT mailing [e-mail]://www.ietf.org/mailman/listinfo/rift   

I thought I had replied to this previously regarding the TTL/HL of 1 vs. 255, thank you for amending that text.
 
There are still two more points that Jim and Alvaro wanted to address (and I agree).
 


Miscabling Considerations


The base spec has made mis-cabling OPTIONAL in a previous version due to the fact that different networks may not agree on what “miscabled”  means. The current version of the applicability draft outlines one of these potential options where level 0 connects directly to level 2 (ToF) bypassing level 1.


I would like to propose some text that considers a couple of other use-cases, so that things are covered more broadly.

 


Multicast vs. Broadcast Implementations


I would like to propose a bit of text for the existing IoT section that talks about “less robust” IP stacks on things like containers or  embedded devices that might require the use of a broadcast implementation of RIFT.

 
I’ll send proposals to the applicability authors in the next week or so.
 
Thank you
Jordan
 

 
Juniper Business Use Only 

From: [e-mail] <[e-mail]> Date: Tuesday, December 26, 2023 at 7:54 PM To: Antoni Przygienda <[e-mail]> Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Jordan Head <[e-mail]>, [e-mail] <[e-mail]>,  [e-mail] <[e-mail]>, Jeffrey (Zhaohui) Zhang <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]> Subject: Re: 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]
 


No problem, two drafts advance together
 


Best Wishes
Yuehua Wei
 




Original




From: AntoniPrzygienda <[e-mail]>



To: 魏月华00019655;[e-mail]  <[e-mail]>;[e-mail] <[e-mail]>;Jordan Head <[e-mail]>;



Cc: [e-mail]  <[e-mail]>;[e-mail] <[e-mail]>;Jeffrey (Zhaohui) Zhang <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;



Date: 2023年12月27日  03:47



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





thanks, happy holidays back. There maybe more overflow from recent reviews on rift towards the applicability draft BTW once they’re resolved by Jordan and me so I’d expect at least one more version …
 


tony

 



 
Juniper Business Use Only
From: [e-mail] <[e-mail]> Date: Tuesday, 26 December 2023 at 04:07 To: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Jordan Head <[e-mail]> Cc: Antoni Przygienda <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>,  Jeffrey (Zhaohui) Zhang <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]> Subject: Re: 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,
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