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

[Jordan Head <[e-mail]>]

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).


  1.  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.


  1.  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/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/rift/zPJ3XaPD7tYWX_q2wBUmyRn37r4/__;!!NEt6yMaO-gk!BTGp6nZBR23NdqtM2LKl2F2fpAPOJMHnJM-rL8HgjdthDTL6br5_nIgSFJjZCb29L7h9k-I6YW6c7NlKUQ$>



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]<mailto:[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,


  1.  I fully support adding this to applicability draft with amedments below
  2.  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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/minutes-118-rift/__;!!NEt6yMaO-gk!HGLMCQkOeNQPYB5USujn9eoduM4VodBQRKyHegktAily7qb2P5tpJU4nRRSes7RltZMxWPWfTNd1WjjRpA$>), 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