BFD at IETF 120?

[Jeffrey Haas]

Working Group,

IETF 120 will be happening in Vancouver in July.  For the last several 
sessions, we've not had a need to meet as we were slowly working through our 
lingering working group items.

https://wiki.ietf.org/group/bfd/current-activities 


As of this email, we've almost reached conclusion on the last items:
- BFD Large is updated and likely ready for WGLC.
- The BFD authentication suite (optimizing authentication, secure sequence 
numbers, stability) have edits queued for the authors to review that should 
resolve the last sets of discussion points on the features.

We've also been notified by evpn and spring that their respective BFD documents 
will be submitted for their last calls soon and copied to BFD for review.

Do we have cause to meet in Vancouver?  

-- Jeff

Re: I-D Action: draft-ietf-bfd-large-packets-05.txt

[Jeffrey Haas]

Reshad,

Sorry about the -06 noise; I posted the template rather than the generated
document.  See -07 for updates.

On Tue, Apr 02, 2024 at 02:40:34PM +, Reshad Rahman wrote:
>  Regarding the grouping for pdu-size, that would also be helpful for BFD 
> clients to include it (if needed) in their config model.
> Regards,Reshad.
> On Friday, March 29, 2024, 01:32:21 PM EDT, Reshad Rahman 
>  wrote:  
>  
>   Jeff, Albert,
> Thank you for the doc update. With work travel and the email flurry on 
> optimized authentication, this one slipped through.
> On the YANG model, I believe the replicated portion with leaf pdu-size etc 
> should be a grouping. 

It's been moved to a grouping in -07.

> I was also thinking that some extra operational data would be useful. I 
> haven't given much thought to it, and I don't know if you have, but something 
> along the lines of pdu-size of received BFD packets.

There's two considerations to not have a operational leaf monitoring the
size of received packets:

1. It can vary substantially. :-)  So, you could always be behind.  And some
flavor of weighted moving average won't be terribly helpful since all it
takes is Detect Mult number of wrong packets to knock the session over.

2. There's no guarantee that the BFD portion of the stack is aware of the
encapsulated size, especially in implementations that do hardware
front-ending of the packet path for BFD.  For implementations where BFD
might be directly part of the receive path, the usual POSIX cmesg data may
be helpful... but that probably should be left as an implementation detail.

> Section 4.1, I think it's worth stating that if padding is enabled on a 
> session which is up, the session will go down if the peer does not support 
> large BFD packets.
> A security section for the YANG is needed, and the impact of setting leaf 
> pdu-size (as stated above). 

Done!

-- Jeff

> Regards,Reshad.
> On Tuesday, January 30, 2024, 03:13:03 PM EST, Jeffrey Haas 
>  wrote:  
>  
>  Working Group,
> 
> After a fumble in -04, -05 updates -03's republish earlier this week with a
> YANG module to configure the padded size.
> 
> Comments are appreciated.  YANG doctor review will be getting requested as
> we hopefuly move this forward soon.
> 
> -- Jeff and Albert
> 
> On Tue, Jan 30, 2024 at 12:09:02PM -0800, internet-dra...@ietf.org wrote:
> > Internet-Draft draft-ietf-bfd-large-packets-05.txt is now available. It is a
> > work item of the Bidirectional Forwarding Detection (BFD) WG of the IETF.
> > 
> >    Title:  BFD Encapsulated in Large Packets
> >    Authors: Jeffrey Haas
> >            Albert Fu
> >    Name:    draft-ietf-bfd-large-packets-05.txt
> >    Pages:  12
> >    Dates:  2024-01-30
> > 
> > Abstract:
> > 
> >    The Bidirectional Forwarding Detection (BFD) protocol is commonly
> >    used to verify connectivity between two systems.  BFD packets are
> >    typically very small.  It is desirable in some circumstances to know
> >    that not only is the path between two systems reachable, but also
> >    that it is capable of carrying a payload of a particular size.  This
> >    document discusses thoughts on how to implement such a mechanism
> >    using BFD in Asynchronous mode.
> > 
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/
> > 
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-bfd-large-packets-05.html
> > 
> > A diff from the previous version is available at:
> > https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-large-packets-05
> > 
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> > 
> 
> 

Re: Resolving lingering issues with BFD authentication drafts

[Jeffrey Haas]

Reshad,


> On Feb 29, 2024, at 2:36 PM, Reshad Rahman  wrote:
> 
> Jeff, 
> 
> The only thing I am still a bit hesitant about is delaying the notification 
> to the BFD clients (that the session is up) until we've successfully moved to 
> the optimized mode. It's not the actual delay, which should be short, but the 
> fact that it's changing the BFD state machine a bit. But I don't see any 
> other way to do this without the risk of bouncing the BFD session. 

It's worth pointing out that the "bfd holddown" features implemented by 
multiple vendors ALREADY does this.  And, when it's in use, the client will 
wait for stuff on the order of seconds to minutes for some providers.

So, while I agree that it's a change, and theoretically a scary one, it's well 
deployed already in some form.

In the interest of honesty, such holddown features didn't interoperate in their 
use terribly well and was the reason for the PROTOCOLS / clients to refine how 
they used BFD - hence the "strict" features.  Again, not a problem with the 
idea of holddown, but rather than RFC 5882 was a bit too general in its advice.


> Regarding "until we've successfully switched over to the optimized 
> mechanism", what does a successful switch mean? Does it mean sending detect 
> mult packets with optimized auth?

I believe it means that both sides are using the optimized mode.  It can't be 
only one side since the potential session drop will only happen when each side 
turns on optimization.

-- Jeff

Re: Resolving lingering issues with BFD authentication drafts

[Jeffrey Haas]

Reshad,


> On Feb 25, 2024, at 5:31 PM, Reshad Rahman  wrote:
> 
> Jeff, overall this looks to be a good way forward, it addresses the main 
> concern I had expressed. 

Excellent.

> On Friday, February 23, 2024, 04:32:55 PM EST, Jeffrey Haas  
> wrote:
> - The optimization procedures currently can have BFD go Up with the initial
>   stronger authentication, then go down once the optimized mode kicks in.
> 
>  That's the scenario where only 1 end supports optimized procedures?

In the current version of the document, yes.  That's an item the suggested 
changes are intended to address.

> Possible ways to address these:
> 
> For BFD optimization:
> [...]

> - Optimized authentication should kick in ASAP when we are in the Up state.
>   I believe this means that we send out at least Detect Mult packets in the
>   strong mechanism and then switch to the optimized mechanism.  This bounds
>   the amount of time when we're not running in optimized mode.
> 
>  Why does optimized procedures need to kick in asap? Is this in case 
> there's an issue with the optimized procedures?

The general concern is not overly delaying the client's idea of when BFD 
transitions to Up.

The suggested changes take us from Up to an internal "pending" state waiting 
for the optimized mode to kick in.  We can theoretically linger there however 
long we like since we've signaled that this change is coming, but it's not 
helpful to the client to linger there longer than necessary.

The suggestion above is really the lowest bound on time we can take for such a 
transition to ensure we can safely transition to ISAAC mode and entrain the 
sequence numbers for the ISAAC algorithm.

> 
> - BFD clients that are expecting optimized authentication SHOULD NOT convey
>  BFD sessions (not clients)?

Session on a client. :-)

>   to their clients that the session is in the Up state until we've
>   successfully switched over to the optimized mechanism.  While this seems
>   contrary to BFD behavior, it's no different than any of the existing
>   "holddown" procedures clients like BGP can implement to ensure that BFD is
>   stable for long enough before using the session.
>  Is this in case there's an issue with the optimized procedures?
> If yes, do we also need some text for the case where optimized procedures 
> fail? e.g., at a certain point we have to stick to strong auth but do we 
> retry eventually (that could cause the session to go down if we do)?

From the client's session perspective, BFD simply is Up/Down as normal.

From the protocol perspective, lingering forever waiting for the optimized mode 
kicking in isn't what we'd want.  So, yes, we need some form of default timeout 
recommended for implementors.

If we repeatedly bounce the BFD session from Up to Down only at the transition 
to the optimized mode, we likely want to dampen that behavior. At least with 
the new code points we have a sense that this transition to the optimized mode 
is the actual problem between devices that have agreed to use that 
authentication type.  

> 
> Thoughts?
>  When transitioning from strong auth to optimized procedures, could we 
> send both types of packets when attempting the transition? The aim being to 
> avoid the BFD session from going down. I haven't thought this through so this 
> may well not hold water.

For the ISAAC procedures, the only requirement is that we believe the other 
side of the session has seen at least one Up packet out of the expected Detect 
Mult packets.  That's sufficient for the entraining procedure.

Once we have entrained the ISAAC session, we should be able to flip in and out 
of the optimized mode at will.

The idea I think you're trying to convey is similar to how other protocols 
handle a graceful rollover for key.  That's normally done by having the 
rollover timeframe being willing to authenticate with both old and new key, not 
having the side generating the packets sending it twice.

For BFD in particular, sending the same PDU with different auth types would 
probably play havoc with the meticulously increasing sequence number 
requirements.  Further, there's no mechanism we have to convey that we've 
successfully processed the rollover.

-- Jeff

Resolving lingering issues with BFD authentication drafts

[Jeffrey Haas]

Here's an attempt to provide a path to resolve the lingering issues in the
authentication drafts.

Core lingering issues:
- The NULL auth method is attackable, but still potentially useful for the
  stability procedures.
- The optimization procedures currently can have BFD go Up with the initial
  stronger authentication, then go down once the optimized mode kicks in.
  Right now, the text doesn't place any bounds on how long it might be until
  the optimized procedures are initiated once the session moves to Up.

  The issue here is less about bouncing the BFD session, but the impact on
  BFD clients.

Possible ways to address these:

For BFD optimization:
- We remove no-authentication and NULL-authentication as methods for the
  optimized session.  This leaves us solely with one defined method that
  both provides good enough security.  It also leaves us room to add other
  authentications in the future that have similar properties.
- Optimized authentication should kick in ASAP when we are in the Up state.
  I believe this means that we send out at least Detect Mult packets in the
  strong mechanism and then switch to the optimized mechanism.  This bounds
  the amount of time when we're not running in optimized mode.
- BFD clients that are expecting optimized authentication SHOULD NOT convey
  to their clients that the session is in the Up state until we've
  successfully switched over to the optimized mechanism.  While this seems
  contrary to BFD behavior, it's no different than any of the existing
  "holddown" procedures clients like BGP can implement to ensure that BFD is
  stable for long enough before using the session.

  This is also not the length of time such features want.  BGP BFD holddown
  is in the multiples of seconds time frame.  I believe we want something
  that is within two Detection Intervals once the session is Up.

  + It should be noted we already require sending out this number of Up
packets in the strong mode for entraining ISAAC.  However, I'm not sure if
our procedures are clear on that point.  To be audited.
- How does a client tell that "we are expecting optimized authentication"?

  We define parallel authentication code points for the procedure.  Today,
  our strong meticulous features are currently meticulous md5 and sha1; code
  points 5 and 3, respectively.  

  We allocate two new code points, "ISAAC-optimized meticulous sha-1" and
  "ISAAC-optimized meticulous md5".  When these code points are used, the
  expectation is the strong cipher is used to get the session to the Up
  state, and the session expects to transition to ISAAC afterwards.  Thus,
  we no longer have the opportunity for an implementation that doesn't
  support optimization to have the session half transition to up using the
  strong mode and fail once the switch attempts to a mode it doesn't
  understand.
- We might want to consider having the shared secret used for both strong
  and optimized mode.  While we've had discussion that we might not want to
  do this, having a common shared secret means that misconfiguration stops
  being the operational consideration that drives the most likely reasons
  for failure of the transition to optimized authentication.
  + This can be a SHOULD for the above reasons.
  + If the operator does not want to use the same shared secret, that's
still fine. It just means they're accepting the potential additional
fragility.
- The NULL auth mechanism is moved out of the optimized draft into the
  stability draft.

For BFD stability:
- The NULL auth method is pulled into this document.
- The NULL auth's procedures are slightly updated such that the sequence
  number SHOULD NOT be used for authentication.  Effectively, it transitions
  to a counter.  This avoids the ability to use it for attacking the
  protocol as noted in prior discussion.
- The NULL auth security properties are no worse at that point than no
  authentication.  
- Existing meticulous methods can be used as well - no change.
- ISAAC can be used when optimized mode is in use.  No change. 
  + ISAAC mode cannot be used alone. Its procedures for entraining the
sequence numbers currently mean it can't be the only authentication.

Lingering cleanup:
- The IANA considerations and the YANG definitions need to be readjusted
  based on where we move things.

Thoughts?

-- Jeff


- 

Re: Attacking BFD with NULL auth

[Jeffrey Haas]

> On Feb 7, 2024, at 12:48 PM, Reshad Rahman  wrote:
> 
> Jeff,
> 
> "No authentication also thus means you can't attack the system by sending a 
> sequence number".
> 
> I agree. But you don't need a seq number with no auth, you just attack by 
> sending a packet to take the session down. That's why I still view NULL auth 
> as (slightly) better than no auth.

I think I see the problem.  At some point in the github merges, we lost text 
that effectively asserts that in the Up state, you cannot change the BFD 
control packet contents excluding the auth section without flipping to the 
strong auth mode.

Basically:
If state is Up:
If authentication is Optimized mode:
Validate authentication, if any, and discard on fail.
Validate control packet contents have not changed.  We are still Up and 
haven't been convinced to change BFD parameters.

Thus, if we're in no-auth, injecting anything other than "I'm still up!" gets 
ignored.  You can keep the session up, but you can't change parameters or take 
the session down.  State changes require strong auth anyway.  The clarification 
is we don't let other parameters get tweaked because portions of the 5880 state 
machinery didn't require either a state change or a poll sequence to  happen.

I'll open a github issue to track this point.

I see also that we have some zombie text:
"Implementations supporting this feature will send BFD packets with 
authentications that always carry a meticulously increasing sequence number. 
This meticulously increasing sequence number prevents replay attacks"

Since we're deciding to support no-auth, this sentence is wrong.  I'll pen a 
second issue.

-- Jeff

Re: Attacking BFD with NULL auth

[Jeffrey Haas]

Reshad,


> On Feb 7, 2024, at 12:21 PM, Reshad Rahman  wrote:
> 
>> ISAAC works for active attacks but I don't understand why no-auth still 
>> works, no-auth is weaker than NULL auth: you don't need to be an active 
>> attacker to knock over a session with no-auth?
> 
> With no-auth, the only thing you can say is "the session is still up".  In 
> the optimized case we're guarding against parameter changes so that's all we 
> get to do.
>  What I don't understand is no-auth still works in the statement below: 
> if NULL auth is impractical, so should no-auth. What I am missing?
> "1. NULL auth and using the sequence numbers becomes impractical to use for 
> optimizing authentication procedures.  ISAAC and no-auth still work. "
> 

No authentication doesn't have sequence numbers.  This means that sequence 
number operations for incrementing are paused at last exchanged sequence number 
in the strong authentication.

No authentication also thus means you can't attack the system by sending 
packets with a sequence number.  The system will be expecting authentication 
types of either the strong auth (protected vs. blind injection by computing the 
digest over the entire PDU), or the expected no-auth.  If you send packets with 
an unexpected auth type, they'll be dropped.

With ISAAC, blind injection can't work unless the injector has access to the 
shared secret, BFD discriminator values, initial sequence number for the ISAAC 
sequence base, and seed.  Discriminator and seed can be discovered by 
intercepting the ISAAC authenticated PDUs.  The initial sequence value has to 
be observed, or inferred by being able to compute the ISAAC table that will 
have the outputs.  The shared secret is thus the core protecting item.

Thus, with ISAAC, you can't push the sequence numbers ahead without being able 
to satisfy ISAAC authentication, even if it's not a digest vs. the entire BFD 
PDU.

With NULL auth, you just need to be able to convince the implementation to 
accept the PDU with a higher sequence number.  This can be done with blind 
injection once you know enough of the BFD session state like discriminators.  
The random discriminator makes this very low likelihood and pushes the attack 
case to someone that is PITM.

-- Jeff

Re: Attacking BFD with NULL auth

[Jeffrey Haas]

Reshad,


> On Feb 6, 2024, at 11:51 AM, Reshad Rahman  wrote:
> 
> Jeff, you mention below that NULL auth with sequence numbers is impractical 
> to use for optimizing authentication. I agree that NULL auth doesn't help 
> with an active attacker, but it still gives protection against "random" 
> attacks?

Unfortunately not in all circumstances.  The attack in this case is a form of 
"blind injection" attack.  As John notes in other bit of the thread, when 
sessions are protected via GTSM, this limits where the attack can come from.  
So, this would apply to whomever can inject packets that successfully get past 
the other necessary checks.

TCP is vulnerable vs. some flavors of this as well.  Long lived tcp sessions, 
such as BGP, need the protections covered by tcp-md5/ao or other protection 
such as ipsec to guard against such things.


> ISAAC works for active attacks but I don't understand why no-auth still 
> works, no-auth is weaker than NULL auth: you don't need to be an active 
> attacker to knock over a session with no-auth?

With no-auth, the only thing you can say is "the session is still up".  In the 
optimized case we're guarding against parameter changes so that's all we get to 
do.

It's the introduction of sequence number checks vs. the existing meticulous 
sequence number procedures we see similar to md5 or sha-1 that introduce the 
problematic edge case.

-- Jeff

Re: Attacking BFD with NULL auth

[Jeffrey Haas]

John,


> On Feb 6, 2024, at 11:00 AM, John Scudder  wrote:
> 
> You’re assuming either an on-LAN attacker (and therefore, that BFD is being 
> used on a multiaccess medium) or multihop BFD here, I take it? Because RFC 
> 5881 tells me GTSM is required if there’s no other authentication.

Correct.  Largely the "person in the middle" style attacks.


-- Jeff

Attacking BFD with NULL auth

[Jeffrey Haas]

My thought over first cup of caffeine for the morning: You can have an active 
attacker attack a session using NULL auth and knock over a BFD session.  This 
is counter to the usual "silly" attack of keeping BFD Up.

Presume the session is in the Up state between A and B and using NULL auth.  
The current expected sequence number at A from B is 100.

An active attacker, seeing that 100 is the sequence number, spoofs packets 
rapidly in order 101..200.

Sequence number procedures are, tersely, "accept the larger sequence number as 
long as it's bigger".  Presume that some portion of that spray of packets gets 
through and moves the sequence number > 100 + 3 before B would have sent 
sequence 101.

B then continues happily sending the meticulously increasing packets, 101, 102, 
103.  These packets are discarded because the sequence number is under the 
"last seen" sequence number.

The session drops.

I don't believe there is any mitigation against this attack in NULL auth.

The impacts of this, if so:
1. NULL auth and using the sequence numbers becomes impractical to use for 
optimizing authentication procedures.  ISAAC and no-auth still work.  
2. BFD stability really wants that increasing sequence number.  This leads to 
using either meticulous types from the strong authentication mechanisms, or 
ISAAC.

Counter observation 1: Stability doesn't really care about the sequence numbers 
from a security standpoint, just a dropped packet standpoint.  The attack 
against stability if the sequence numbers aren't used for authentication of the 
session to drop the session is to trigger an "unstable" event and whatever 
trigger might be tied to that mechanism as a client.

Counter observation 2: If the sequence numbers are ignored as a mechanism for 
taking the session down, you can't use it to prevent PITM attacks, but it's no 
worse than no-auth.  The periodic strong authentication becomes more important.


-- Jeff

Re: I-D Action: draft-ietf-bfd-optimizing-authentication-14.txt

[Jeffrey Haas]

Reshad,


> On Feb 5, 2024, at 4:18 PM, Reshad Rahman  
> wrote:
> 
> Hi,
> 
> I've provided some comments to the authors privately, sharing them here to 
> restart/continue the discussion on the WG alias.
> 
> My main technical concern is in the changes to BFD auth mode: when 
> transitioning to No auth for up packets, we don't know if the other end 
> supports procedure changes from this document. So the other end could just 
> drop the unauthenticated UP packets and the session will go down, eventually 
> go back up, in a loop. The counter-argument which has been made is that this 
> issue isn't new e.g. if one end is misconfigured for BFD auth, the session 
> will not come up, so this boils down to being a typical config issue. I do 
> agree partially, but I think the changes in this document can make things 
> worse than usual in that the session will come up, go down very quickly and 
> keep on ding that. We don't have any room left in the BFD header to indicate 
> the desired behaviour. The only thing I could think of is to use Poll 
> sequence with A=0 (on top of the expected A=1 packets), and transition to 
> only A=0 if the Poll sequence succeeds (and the Poll sequence has to be for N 
> packets where N is equal to "remote multiplier"). Jeff has pointed out that 
> Xiao Min has suggested a similar solution in 
> https://datatracker.ietf.org/doc/html/draft-xiao-bfd-padding-alteration-00 
> .

Related notes from those conversations for the mailing list:

- A poll mechanism to test for a new behavior where the possibility exists for 
the poll packets to be lost means you have to be mindful of Detect Mult 
(permitted number of lost packets) and timers.  For example, a one packet poll 
is enough to probe if the packet isn't lost in either direction.  In case of 
loss, you don't want to do the poll for Detect Mult packets because if the drop 
is the result, the session goes down.

Mitigations may include temporarily changing the Detect Mult.

- One mitigation for the repeatedly bouncing sessions is to have the BFD 
session keep state.  If the implementation switches to optimized mode and the 
session drops, don't permit the session to automatically restart if it does 
this after more than X tries.  Require the operator to clear the state?


> 
> In terms of editorial comment, I am now questioning the term NULL auth since 
> we also use the term No auth. Suggestions: Meticulous sequence number, 
> sequence number or something along those lines.
> 
> YANG comments/questions/suggestions:
> 
>  identity no-auth {
>base key-chain:crypto-algorithm;
>  It is a bit odd to have a crypto algorithm which says none. I wonder if 
> a boolean would have been better to indicate no-auth.

We're looking for consistency in configuration.

If optimized procedures require another mechanism to be chosen for the 
optimized Up side of things, and that's done via the keychain, you need a valid 
keychain entry.

Further, properties such as "when is this valid" and other keychain properties 
are still valid.



> 
>  identity null {
>base key-chain:crypto-algorithm;
>  null-auth to be consistent with no-auth (assuming we keep NULL auth)?

If we don't change the name, sure.

> 
>leaf reauth-interval {
>  when "../optimized-auth = 'true'";
>  type uint32;
>  units "microseconds";
>  I think it's overkill to have this in microsecs. Other intervals use 
> micro secs because we exchange timer values in micro secs. This value is not 
> exchanged so we don't need microsecs. Or are you doing this for consistency?

This is a headache elsewhere in YANG modules.  While the units clause lets us 
be clear that leaf A and leaf B aren't directly comparable if they don't share 
the units, it still trips people up.

That said, it's also not forbidden.  re-auth on the interval of seconds seems 
reasonable to me.

And, as I mentioned in a prior thread, the 60 second value that's been chosen 
is rather arbitrary.

>  Mention that value of 0 means that we don't do periodic reauth with 
> strong authentication.

We could probably do that, especially in support of ISAAC procedures.


> 
>leaf up-auth-type {
>  Since this points to a key-chain, rename to something like 
> opt-auth-key-chain?

Also reasonable.  The move to the "opt" name token in the draft is largely over 
the most recent discussion.

>  type key-chain:key-chain-ref;
>  must "(../optimized-auth = 'true') and " +
>   "(../bfd-ip-sh:meticulous = 'true')";
>  Why the check for meticulous? Is the reasoning that for non-meticulous 
> opt-auth isn't needed or is it something else?

The optimized procedures require meticulous authentication.  The NULL and ISAAC 
methods use this mode to prevent PITM.  If you don't regularly increment the 
numbers, you're defining the interval in which the "attack" (silly as it is to 
some 

Re: BFD authentication package

[Jeffrey Haas]

Mahesh correctly points out that opt-13 is the 2022 version.  The updated 
version from the recent github work should be published hopefully soon.

-- Jeff (need. more. caffeine...)

> On Feb 5, 2024, at 10:06 AM, Jeffrey Haas  wrote:
> 
> Working Group,
> 
> There's been a lot of behind the scenes work in github to try to get our 
> bundle of authentication features completed.  As of today:
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-13
>  
> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-13>
>  - Updated 2 Feb.
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-13
>  
> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-13>
>  - Updated 4 Feb
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-stability-12 
> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-stability-12> - Updated 
> 31 Jan.
> 
> The chairs would like to encourage you to review these documents together.  
> 
> Reshad has some questions related to bfd optimization that he'll be bringing 
> to the mail list for broader discussion.
> 
> I believe once Reshad's thread has resolved, we'll be ready to request 
> various directorate reviews, and likely to also call for Working Group Last 
> Call.
> 
> Meanwhile, we look forward to your reviews.
> 
> -- Jeff and Reshad
> 

BFD authentication package

[Jeffrey Haas]

Working Group,

There's been a lot of behind the scenes work in github to try to get our bundle 
of authentication features completed.  As of today:

https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-13
 

 - Updated 2 Feb.
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-13 

 - Updated 4 Feb
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-stability-12 
 - Updated 
31 Jan.

The chairs would like to encourage you to review these documents together.  

Reshad has some questions related to bfd optimization that he'll be bringing to 
the mail list for broader discussion.

I believe once Reshad's thread has resolved, we'll be ready to request various 
directorate reviews, and likely to also call for Working Group Last Call.

Meanwhile, we look forward to your reviews.

-- Jeff and Reshad

Re: bfd - Not having a session at IETF 119

[Jeffrey Haas]

> On Feb 5, 2024, at 1:12 AM,   
> wrote:
> Just one small update to the wiki, the title of 
> draft-ietf-bfd-unaffiliated-echo has been changed from "Unaffiliated BFD Echo 
> Function" to "Unaffiliated BFD Echo" since -03 version.
> 
> 

Fixed. :-)

-- Jeff

Re: bfd - Not having a session at IETF 119

[Jeffrey Haas]

While the session request tool downgraded our area director into one of the 
chairs, it's our intention to not meet at the upcoming IETF 119 in Brisbane.

Current status of the working group is on the wiki:
https://wiki.ietf.org/en/group/bfd 

It's our hope that prior to IETF 119 we'll have fully updated and ready for 
last call versions of:
draft-ietf-bfd-optimizing-authentication
draft-ietf-bfd-secure-sequence-numbers
draft-ietf-bfd-stability

Once those documents have been re-issued, we'll be asking for directorate 
review for them.

draft-ietf-bfd-unaffiliated-echo has been submitted for publication by the IESG 
and we're waiting on that process.

draft-ietf-bfd-large-packets has been refreshed, has an implementation at 
Juniper and was recently updated to add a YANG module covering its behavior.  
The authors (including myself) are in discussions with Xiao Min to see if his 
recent proposal is an appropriate fit to be incorporated in this draft in some 
fashion, or whether to keep it as a separate draft.

In non-bfd WG news, RFC 9521 came out for BFD for Geneve.  Congratulations to 
the authors!

BFD for BIER is apparently ready for WGLC:
https://mailarchive.ietf.org/arch/msg/bier/j5czUxHaqJRcmnrYxe8RfqEGUm0/ 


draft-ietf-spring-bfd appears to be ready for WGLC:
https://mailarchive.ietf.org/arch/msg/spring/qg3anN8M8Ks-rjkpJ6pXqmyjrw4/ 


This bit of work in the MPLS WG has impacts on RFC 5884, BFD for MPLS LSPs:
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-lspping-norao-06 


Greg has raised issues covering RFC 5884 in MPLS.  The chairs believe if any 
work needs to be done, it's best done as a -bis to RFC 5884 in BFD:
https://mailarchive.ietf.org/arch/browse/mpls/?q=draft-mirsky-mpls-bfd-bootstrap-clarify
 


If I've missed anything else, please let the chairs know and we'll get the wiki 
updated.

-- Jeff and Reshad


> On Feb 2, 2024, at 10:24 AM, IETF Meeting Session Request Tool 
>  wrote:
> 
> 
> 
> John Scudder, a chair of the bfd working group, indicated that the bfd 
> working group does not plan to hold a session at IETF 119.
> 
> This message was generated and sent by the IETF Meeting Session Request Tool.
> 
> 

Re: [mpls] Review of draft-mirsky-mpls-bfd-bootstrap-clarify

[Jeffrey Haas]

+bfd WG.

Some original comments to Adrian were:

https://mailarchive.ietf.org/arch/msg/rtg-bfd/SYouXfNrVyKHErqacOuM2fICzMc/ 


Apparently, Greg didn't consider this worth holding his peace over.

https://www.rfc-editor.org/errata/eid5085 
 was filed and accepted as a 
clarification for RFC 5884 as part of a prior round of this discussion.

LSP Ping is getting its norao update currently in MPLS.  While it's my opinion 
that the current set of changes to that document don't negatively impact 
backward compatibility with RFC 5884, it's a normative enough change that 
perhaps it's worth moving forward with the small updates to RFC 5884.

In my opinion, the appropriate work is to take this to BFD for RFC 5884-bis, 
which would be co-reviewed with MPLS.  I believe we can get at least one of the 
original authors to pick up that work.

That said, the BFD chairs are completely unaware of anyone experiencing any 
sort of confusion covering RFC 5884 procedures other than Greg.

-- Jeff
 


> On Jan 24, 2024, at 2:55 PM, Carlos Pignataro  wrote:
> 
> Hi!
> 
> Review of draft-mirsky-mpls-bfd-bootstrap-clarify
> Version 05
> Type Getting Ready for WG Adoption
> Team MPLS WG Review Team
> Reviewer: Carlos Pignataro 
> 
> I have been asked to provide a ‘getting ready for WG adoption’ review of this 
> document, on behalf of the MPLS WG review team.
> 
> There are generally two relevant questions at this stage:
> 
> 1. knowing whether the document is in scope for the working group, and
> 2. knowing whether the document is ready to be considered for WG adoption
> 
> My perspective is that:
> 
> 1. Maybe - RFC 4884, the RFC that this document would update if approved, was 
> progressed as draft-ietf-bfd-mpls in the bfd wg. As such, I wonder if that 
> ought to be followed here. From a practical standpoint, both WGs (mpls and 
> bfd) would have to review this document, but it is a chair decision and 
> guidance whether this should live in mpls or bfd (and frankly I have no 
> strong position either way so long as both WGs are in the loop, simply 
> pointing historic datapoints.) The document is clearly in scope on the 
> intersection of both WGs, and historically was in bfd.
> 
> 2. Yes – this document addresses clear clarifications for implementation 
> interoperability. Granted, this protocol is deployed without these 
> clarifications, but are (at least) theoretical gaps.
> 
> A couple of further comments, since I read the document. Overall, well 
> written and clear, achieves its goal, and:
> 
> a. Backwards compatibility is paramount, and neither of those two words 
> appear in the document. I recommend a section detailing implications.
> 
> b. Section 5, IPv6, seems like an after-though, since it is not mentioned in 
> the Abstract. Further, that case and explanation is well covered in RFC 8029, 
> and as such seems like a distraction.
> 
> c. There are various nits and an editorial pass would help with clarity. 
> These include things like unqualified “echo reply” uses.
> 
> Thanks,
> 
> Carlos Pignataro
> 
> ___
> mpls mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

Re: Optimizing Authentication - periodic re-authentication

[Jeffrey Haas]

Reshad,

> On Jan 30, 2024, at 12:28 AM, Rahman  wrote:
> 
> Jeff, good catch.
> 
> We can document both ways, ie we can let implementations decide which of the 
> 2 methods below they prefer? Or is the concern that this will cause a DISCUSS?

Mahesh has proposed the fix for the next rev in this pull request:

https://github.com/bfd-wg/optimized-auth/pull/19/files 


-- Jeff

Re: I-D Action: draft-ietf-bfd-large-packets-05.txt

[Jeffrey Haas]

Working Group,

After a fumble in -04, -05 updates -03's republish earlier this week with a
YANG module to configure the padded size.

Comments are appreciated.  YANG doctor review will be getting requested as
we hopefuly move this forward soon.

-- Jeff and Albert

On Tue, Jan 30, 2024 at 12:09:02PM -0800, internet-dra...@ietf.org wrote:
> Internet-Draft draft-ietf-bfd-large-packets-05.txt is now available. It is a
> work item of the Bidirectional Forwarding Detection (BFD) WG of the IETF.
> 
>Title:   BFD Encapsulated in Large Packets
>Authors: Jeffrey Haas
> Albert Fu
>Name:draft-ietf-bfd-large-packets-05.txt
>Pages:   12
>Dates:   2024-01-30
> 
> Abstract:
> 
>The Bidirectional Forwarding Detection (BFD) protocol is commonly
>used to verify connectivity between two systems.  BFD packets are
>typically very small.  It is desirable in some circumstances to know
>that not only is the path between two systems reachable, but also
>that it is capable of carrying a payload of a particular size.  This
>document discusses thoughts on how to implement such a mechanism
>using BFD in Asynchronous mode.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-bfd-large-packets-05.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-large-packets-05
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 

BFD for large packets

[Jeffrey Haas]

[Speaking as an individual contributor.]

As part of trying to push BFD WG work to conclusion, I've re-issued BFD for
large packets.  Our last big push on the document was back in 2019,
including a first and not conclusive pass toward Working Group Last Call.

Since then, Juniper has done an initial implementation of the draft.  Les
might find it vindicating that part of the learnings from that
implementation were that naive implementations have interesting scaling
headaches.  That said, the outcome of that work were mostly the same as the
rest of the use of BFD: you have to work based on the scaling of your
platform.  Optimization work is under way to push our scaling up, but those 
implementation details rather than something that impacts the draft text.

There are two lingering items Albert and I will be addressing in the near
term, both tracked in the github I did the original work in[1]:

1. We should add YANG support for this feature.
2. There was a request from Xiao Min to consider whether work in his padding
   alteration proposal[2] was appropriate to directly incorporate in the large
   packets draft.  Albert and I will be considering what such a fit would
   look like and work with Xiao Min on the text.

   Reshad had indicated back in 2019 that incorporating such changes would
   likely require polled support from the Working Group.  We'll thus do some
   text for WG review prior to including it in future versions of the draft
   directly.

-- Jeff

[1] https://github.com/jhaas-pfrc/bfd-large-packets
[2] https://datatracker.ietf.org/doc/html/draft-xiao-bfd-padding-alteration-00

- Forwarded message from internet-dra...@ietf.org -

Date: Sun, 28 Jan 2024 13:33:51 -0800
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Cc: rtg-bfd@ietf.org
Subject: I-D Action: draft-ietf-bfd-large-packets-03.txt

Internet-Draft draft-ietf-bfd-large-packets-03.txt is now available. It is a
work item of the Bidirectional Forwarding Detection (BFD) WG of the IETF.

   Title:   BFD Encapsulated in Large Packets
   Authors: Jeffrey Haas
Albert Fu
   Name:draft-ietf-bfd-large-packets-03.txt
   Pages:   7
   Dates:   2024-01-28

Abstract:

   The Bidirectional Forwarding Detection (BFD) protocol is commonly
   used to verify connectivity between two systems.  BFD packets are
   typically very small.  It is desirable in some circumstances to know
   that not only is the path between two systems reachable, but also
   that it is capable of carrying a payload of a particular size.  This
   document discusses thoughts on how to implement such a mechanism
   using BFD in Asynchronous mode.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-bfd-large-packets-03.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-large-packets-03

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


- End forwarded message -

Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas]

> On Jan 25, 2024, at 6:39 PM, Mahesh Jethanandani  
> wrote:
> 
>> On Jan 24, 2024, at 12:19 PM, Jeffrey Haas > <mailto:jh...@pfrc.org>> wrote:
> Ok. I have added a couple of leafs. One is called ‘up-auth-type’ which is of 
> type iana-bfd-types:auth-type that can be used to indicate what auth-type 
> should be used once the session reaches UP state. It should be one of NULL 
> Auth type or Meticulous ISAAC. The second is a strong-auth leaf which is also 
> of type iana-bfd-types:auth-type which specifies one of the strong 
> authentication mechanisms (not including simple password).

I've started annotating the repository with comments to help converge there.

The thing I think is missing in the most recent round is that the up-auth 
flavor of things is really a keychain entry of its own, or something similar.  
As per the Meticulous Keyed ISAAC proposal, there may be distinct 
authentication parameters, like a secret, vs. the one used for strong.

> 
>> 
>> If you use NULL auth for the optimization procedures, you require no 
>> additional authentication parameters.  
> 
> Not quite. We still have the 'strong-auth-interval’ that specifies how often 
> we need to perform a strong authentication when NULL Auth is used, something 
> we discussed below.

Agreed. I had meant the secret.

>> If you use Meticulous Keyed ISAAC, you require a key-id and a shared secret, 
>> same as you do for SHA-1, MD5, etc.
> 
> True, but in the base BFD YANG model we point to the key-chain for it, which 
> is what ISAAC will have to use.

See above; the secret may be different.

As I flagged in the review, I'll check the keychain semantics in more detail 
tomorrow.


> 
>> 
>> Thus what is needed for the optimization case is "do optimization, here's my 
>> second mechanism and its configuration".
> 
> Ok. The tree diagram currently looks like this:
> 
> augment /rt:routing/rt:control-plane-protocols
> /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
> /bfd-ip-sh:sessions/bfd-ip-sh:session
> /bfd-ip-sh:authentication:
> +--rw optimized-auth? boolean {optimized-auth}?
> +--rw up-auth-type?   iana-bfd-types:auth-type
> +--rw strong-auth?iana-bfd-types:auth-type
> +--rw strong-auth-interval?   uint32
> 

I'll also note that the existing YANG module includes a leaf for meticulous 
mode which can help with the bfd-stability work.

> 
> But stability can be detected even when A bit is not set. Do we need to 
> configure NULL auth to detect loss of packets?

It cannot be detected without the a-bit.  As I noted in the review, "NULL" auth 
is not "a-bit zero", it's a specific authentication type that includes the 
sequence number.

Raw RFC 5880 BFD without authentication DOES NOT contain any sequence numbers.  
That's why we need the NULL auth.

I'm starting to wonder if we need a rename of "NULL" to something else because 
as someone clued on BFD you're wanting it to mean "no authenticaton". You 
wouldn't be the only one.

> 
> If Meticulous Keyed ISAAC is used as the second bit of authentication when 
> optimization is configured, then we do not need the ’secure-sequence-number’ 
> flag. 

Exactly.  And, as Alan keeps helping to point out, we really don't have a 
"secure sequence number" feature any more.  It evolved into a full 
authentication type.

-- Jeff

Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas]

Mahesh,

I don't think we're too far off from each other's perspective.


> On Jan 23, 2024, at 9:15 PM, Mahesh Jethanandani  
> wrote:
> 
>> On Jan 23, 2024, at 10:30 AM, Jeffrey Haas > <mailto:jh...@pfrc.org>> wrote:
> 
> I see that there is some confusion that still needs to be cleared. I brought 
> it up, but apparently I did not do a good job of it.
> 
> You mention two authentications proposed for Optimized auth. I think there is 
> only one, i.e. the one that uses NULL Auth. Meaning, in Optimized auth mode, 
> you start with strong auth for state transitions, and once the session is in 
> UP state, transition to NULL auth, with occasional strong auth to prevent 
> MITM attack.
> 
> The Meticulous Keyed ISAAC in my mind is independent of Optimized auth. It 
> can be enabled by itself, or along with Optimized auth to secure the sequence 
> number.
> 
> Did you have something else in mind?

A boolean of "doing optimization" isn't sufficient on its own.

Optimization means you have the original strong auth mechanism to start. E.g. 
sha-1.
Optimization means you switch to the other auth once you're in the Up state.  
We have two use cases we're considering: NULL auth (a new auth method), 
Meticulous Keyed ISAAC (a new auth method).

If you use NULL auth for the optimization procedures, you require no additional 
authentication parameters.  

If you use Meticulous Keyed ISAAC, you require a key-id and a shared secret, 
same as you do for SHA-1, MD5, etc.

Thus what is needed for the optimization case is "do optimization, here's my 
second mechanism and its configuration".


> 
>> 
>> Further, for the bfd-stability feature, we need to have the ability to pick 
>> the meticulous authentication that will be used potentially in addition to 
>> non-meticulous authentication that might be stronger. 
>> 
>> I think this is pushing us toward having a secondary bit of authentication 
>> configured for the session and a selector for the mode of why it's needed: 
>> optimized vs. stability.
>> 
>> Working through both use cases will likely drive the outcome.
> 
> I agree with you on the question of using a meticulous auth mechanism when 
> stability is enabled, and something that you highlight on the other thread. 
> But could it be as simple as some text that says that when stability is 
> enabled, only meticulous auth should be used. I am not sure what you mean 
> when you say “ability to pick the meticulous authentication that will be used 
> …”. The base BFD YANG model does not allow us to specify what bfd.AuthType 
> will be used. Just the key-chain and whether we want meticulous auth or not.
> 
> Here are some of the possible scenarios that I can think of, what config 
> would apply, and what would be the behavior.
> 
> - No auth, no secure sequence number, no stability. No new config. Things 
> will work as defined in RFC 5880.
> - Strong auth, no secure sequence number, no stability. No new config. Things 
> will work as defined in RFC 5880.

These two are good.

> - Optimized auth, no secure sequence number, no stability. 'optimized-auth' 
> flag is set to true, along with an interval for strong auth. The system 
> decides what strong auth it uses for state change and occasional auth.

The mechanism for the optimized Up state needs configuration.  See above.

> - No auth, secure sequence number, no stability. A config variable 
> 'secure-sequence-number' is set to true, and the system uses ISAAC.

Invalid configuration.  Meticulous Keyed ISAAC is only applicable to packets in 
the Up state due to the lack of a digest computed over the whole PDU.


> - No auth, no secure sequence number, stability. A config variable of 
> ‘stability' is set to true. System uses the increasing sequence number to 
> detect drops.

What this would translate to is "NULL auth is the only authentication mechanism 
configured". 

> - Optimized auth, secure sequence number, no stability. 'optimized-auth' and 
> 'secure-sequence-number' are set to true. System picks a strong auth for 
> state transitions and occasional auth, and NULL auth otherwise. In parallel, 
> it uses ISAAC to secure the sequence number.

There's no "system picks", the user has to specify what we start with because 
the strong auth requires configuration.  E.g. sha-1.

In this example, if "secure sequence number" is set, it means the optimization 
configuration uses Meticulous Keyed ISAAC as its second bit of authentication 
for that mode, and it will need its configuration parameters.

In the scenario above, if the primary authentication mechanism is Meticulous, 
the system can provide stability data.  However, if it uses non-Meticulous 
MD-5, we can't run the stability procedures until w

Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas]

Mahesh,


> On Jan 23, 2024, at 1:18 PM, Mahesh Jethanandani  
> wrote:
> 
> I am proposing two config variables that I think that are pertinent to 
> optimized configuration, and I can put a small YANG model that augments BFD 
> YANG model to demonstrates it. They are:
> 
> - optimized-auth flag: A boolean flag, when set to true, the implementation 
> would like to make use of optimized auth for the session in question.

We have two authentications proposed for optimization: NULL and Meticulous 
Keyed ISAAC.  Were you expecting another leaf and the relevant keychain 
parameters for these to be defined elsewhere and tied in?

Further, for the bfd-stability feature, we need to have the ability to pick the 
meticulous authentication that will be used potentially in addition to 
non-meticulous authentication that might be stronger. 

I think this is pushing us toward having a secondary bit of authentication 
configured for the session and a selector for the mode of why it's needed: 
optimized vs. stability.

Working through both use cases will likely drive the outcome.



> - strong-auth-interval: A uint32 value that takes a microsecond value for the 
> interval after which the session MUST try a strong authentication mechanism 
> to prevent a MITM attack. The default value is default value of 
> required-min-rx-interval as defined in the BFD YANG model, times the 
> local-multiplier with a default value of 3 for a total of 300.

The danger of saying "pick a reasonable value" is the back and forth of what 
should be reasonable.  3s is certainly better than doing expensive 
authentication every 30ms.  Would every 30s?  Every 5m? 

I would recommend something probably in the minute time frame. 

I would also suggest we want text that says "this value will have jitter 
applied to it to avoid self-synchronization of expensive authentication 
operations".  Basically, if you presume a system that is doing the expensive 
thing every N seconds, we don't want it trying to do that expensive thing for 
every single session all at the same time.

> 
> Both these variables can be protected with a feature statement that 
> implementations will enable if they want to support optimized authentication.

Perfect.

> 
> Is that what you were looking for?

This is the right direction!

-- Jeff

Re: I-D Action: draft-ietf-bfd-stability-11.txt

[Jeffrey Haas]

Authors,

Thanks for the refresh on the stability document as we work toward winding
up the authentication feature bundle.

A few comment from the update using the id-nits line numbering:

On Mon, Jan 22, 2024 at 04:50:53PM -0800, internet-dra...@ietf.org wrote:
> Internet-Draft draft-ietf-bfd-stability-11.txt is now available. It is a work
> item of the Bidirectional Forwarding Detection (BFD) WG of the IETF.
> 
>Title:   BFD Stability
[...]
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/

126 4.  BFD Null-Authentication Type

128The functionality proposed for BFD stability measurement is achieved
129by appending an authentication section with the NULL Authentication
130type (as defined in Optimizing BFD Authentication
131[I-D.ietf-bfd-optimizing-authentication] ) to the BFD control packets
132that do not have authentication enabled.

This section is correct, but not wholly so.

Using the section below:

134 5.  Theory of Operation

136This mechanism allows operators to measure the loss of BFD control
137packets.

139When using MD5 or SHA authentication, BFD uses an authentication
140section that carries the Sequence Number.  However, if non-meticulous
141authentication is being used, or no authentication is in use, then
142the non-authenticated BFD control packets MUST include an
143authentication section with the NULL Authentication type.

These two sections together are trying to articulate the more fundamental
requirement: Meticulous authentication carries an increasing sequence number in
each BFD packet, regardless of the type.  When meticulous authentication is in
use, dropped packets can be detected by looking at the sequence numbers.

Thus, "no authentication" isn't a valid scenario, it's "minimally, use the NULL
auth type".  The same applies to simple password.  

Non-meticulous can't help us here.  There's thus the option with non-meticulous
is interspersing non-meticulous with a meticulous mode that is inexpensive
enough.  NULL is an option, as is Meticulous Keyed ISAAC.

The configuration requirement is thus similar to the discussion resolving in the
optimizing authentication thread.  There needs to be a "primary" authentication,
with a set of acceptable "secondary".  For optimizing authentication scenarios,
this is a "stronger" for startup and transitions, and a "weaker" mode.  For bfd
stability, it's the allowable mix such that the full mix is always meticulous.

155The first BFD authentication section with a non-zero sequence number,
156in a valid BFD control packet, processed by the receiver is used for
157bootstrapping the logic.  When using secure sequence numbers, if the
158expected values are pre-calculated, the value must be matched to
159detect lost packets as defined in BFD secure sequence numbers
160[I-D.ietf-bfd-secure-sequence-numbers].

The text covering secure sequence numbers is stale and no longer covers current
Meticulous Keyed ISAAC procedures.  I think you can fix this simply by dropping
that text.


-- Jeff

Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas]

Mahesh,


> On Jan 22, 2024, at 5:15 PM, Mahesh Jethanandani  
> wrote:
> 
>> On Jan 19, 2024, at 4:14 PM, Mahesh Jethanandani > > wrote:
>> At the same time, if 'secure-seq-num' is configured as ’true’, the sequence 
>> number is generated as defined by I-D.ietf-bfd-secure-sequence-numbers, and 
>> inserted into the packet. The only question I ask is, if “optimized auth” is 
>> enabled, and when there is a state transition, the packet is “fully” 
>> authenticated by selecting bfd.AuthType as one of the non-zero values (but 
>> not NULL-auth). Do we need to generate a secure sequence number at that 
>> time? Or is it easier/simpler to let it continue generating the secure 
>> sequence number, and not deal with “lost” packets as the session transitions 
>> from bfd.AuthType with a non-zero value and NULL-auth.
> 
> Want to make sure that this is clear enough (here), and if you think text to 
> that effect should be added to the draft.

I'm not really looking for text that says the procedure sets specific bfd 
variables in order to say what is going on the wire.

However, what's needed is discussing that we're switching from a primary 
configuration for authentication with "strong" properties to a "weaker" one for 
the optimization.  We also need to discuss that for certain "weaker" 
authentications, like NULL, we may need to periodically do the strong 
authentication to ensure we haven't been MITMed.

And for that periodic strong auth check, what's the configuration element and 
what's the recommended time to do it?  For example, a few times an hour?  I 
suspect we'll pick a value and it'll immediately get hate mail from the 
security directorate no matter what so my recommendation is to pick something 
the authors think is reasonable and we'll iterate that conversational point in 
that thread.

-- Jeff

Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas]

> On Jan 21, 2024, at 8:23 PM, Alan DeKok  wrote:
> 
>  (removing optimizing authentication)
> 
>> On Jan 21, 2024, at 3:37 PM, Jeffrey Haas  wrote:
>> I'd not pushed for those details to be spelled out because the only 
>> legitimate way an implementation can accomplish this is, as above, through a 
>> poll sequence.
> 
>  Ah, I had forgotten that.  I've been working on the ISAAC bits, and was 
> studiously ignoring the rest of the BFD state machine.

I've sent out a correction on this detail to the bfd mail list.  But 
fundamentally, it's not a requirement that we restate the procedures, just nod 
they they're already covered.


> 
>>> Doing that would address pretty much all of the issues related to not 
>>> authenticating the packet.  Either a received packet is byte-for-byte 
>>> identical to what we expect (plus ISAAC key), or it's not, and we drop it.
>> 
>> ... is perhaps a late understanding for you as the expert in ISAAC rather 
>> than BFD, we certainly can spell it out in a sentence or two in the secure 
>> sequence numbers document
> 
>  Perhaps not quite too late.  I can add some text to the document before 
> another rev is sent out.
> 
>  The text should say that none of the fields in the header normally change.  
> [RFC5880] Section 6.8.3 says:
> 
>   If either bfd.DesiredMinTxInterval is changed or
>   bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
>   initiated
> 
>  There's no similar text for "Required Min Echo RX Interval" changes, but 
> that's fine.

I think the relevant bit of RFC 5880 is:
https://datatracker.ietf.org/doc/html/rfc5880#autoid-31 
<https://datatracker.ietf.org/doc/html/rfc5880#autoid-31>

  If the A bit is set, the packet MUST be authenticated under the
  rules of section 6.7 
<https://datatracker.ietf.org/doc/html/rfc5880#section-6.7>, based on the 
authentication type in use
  (bfd.AuthType).  This may cause the packet to be discarded.

Basically, if you have authentication configured, and you're expecting it to be 
used, someone doesn't blindly get to send you something else and knock your 
session over.

Thus it's feasible for ISAAC mode to cause parameters changes, even if that's 
not necessarily what we want.  Clarifying that we don't want that is in the 
purview of the optimizing draft basically saying "since the methods used for 
altering BFD session parameters might not be authenticated, stronger 
authentication MUST be used" and then otherwise refer back to the motivations 
for the draft.


> 
> The ISAAC document also could to be updated to state that a stronger 
> authentication method is used for every Poll Sequence, too.  Because that 
> signifies a change of session state (management information), even if the 
> bfd.SessionState variable remains in "Up".

I think this is mostly making sure the optimizing authentication authors review 
their procedural text vs. these details and then we make sure the ISAAC 
document is in harmony with it.



> 
>  For me, that's the main reason to switch to a stronger Auth Type.
> 
>  The ISAAC document can then say that the BFD packets can at least be 
> verified to be unchanged if:
> 
> * the packet information is cached during an Auth Type which verifies the 
> packet contents
> 
> * the same packet header (modulo Sequence Number) is seen for all packets 
> using ISAAC
> 
>  I'll try to work up some text tomorrow.

Note that the text we had last reviewed on your branch had reached broader 
consensus.  I'd suggest that text get merged and these details be worked out 
separately.

-- Jeff

> 
>  Alan DeKok.

Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas]

Alan,


> On Jan 21, 2024, at 8:09 PM, Alan DeKok  wrote:
> 
> On Jan 21, 2024, at 3:43 PM, Jeffrey Haas  wrote:
>>> i would lean towards forbidding "simple password", unless it uses a 
>>> different password than is used for the stronger authentication methods.  
>>> Otherwise it leads to the password being exposed.
>> 
>> I'm supportive of that.  What text would you recommend?
> 
>  I'll push some text to github, but we could add text to the section 
> "Updating RFC 5880":
> 
>  The use of "Simple Password" authentication is  NOT RECOMMENDED.  There is 
> little security added by exposing a plain-text password "on the wire".

I'd skip the second sentence.

> Where Simple Password authentication is used, the password MUST NOT be used 
> for other Auth Type methods.  Using Simple Password authentication for one 
> packet and then the same password (for example) for Keyed SHA1 authentication 
> would expose the password, and negate all security gained through the use of 
> Keyed SHA1.

> Q: 5880 says that Auth Key ID will identify a particular key. But it's not 
> clear if the Auth Key ID field is meant to be different for each Auth Type, 
> or do all Auth Types share the same Auth Key ID?

The specification is silent on this matter.  My interpretation is that it's 
always a local matter between two authenticating systems.

The IETF keychain YANG model treats the keychain as a uint64 on top of a 
individual keychain and keychains are bound to individual protocols.

To pick my own company's implementation, the keychain has a key id 0..63 on an 
individual chain that may be applied to specific BFD sessions:
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/key-edit-security-authentication-key-chains.html
 
<https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/key-edit-security-authentication-key-chains.html>

> 
>> Since we now have split motivations, we need text that lets us decide when 
>> we should periodically use stronger authentication, or not, for staying in 
>> the Up state.
> 
>  This should be in the optimizing authentication draft, I suppose.  I have 
> fewer opinions there.

Agreed.  When to change to a specific authentication is the scope for that 
draft.

> 
>  Off of the top of my head, swapping it once per second seems too high.  Once 
> per day may be too low.  It all depends on how often the links stay up.

Sometimes on the order of months. :-)

-- Jeff

Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas]

Correction for the pedants on the list. :-)

> On Jan 21, 2024, at 3:37 PM, Jeffrey Haas  wrote:
> 
> 
> A reasonable procedure for an implementation of ISAAC is verifying that the 
> contents do not vary.  For the BFD state machinery, any changes to those 
> fields is expected to be accomplished through a poll sequence, unless we're 
> going Down/AdminDown, in which case we're also wanting strong authentication.

Several changes to BFD states DO NOT require a poll sequence and can simply be 
done without coordination.  My memory on this detail were incorrect.

However, authentication still needs to pass in order for it to do so.

-- Jeff

Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas]

> On Jan 20, 2024, at 7:45 PM, Alan DeKok  wrote:
> 
> On Jan 19, 2024, at 7:14 PM, Mahesh Jethanandani  
> wrote:
>> In my mind, and my co-authors can correct me if my understanding is 
>> incorrect, I do not see "optimized auth" as a choice between "NULL-auth" and 
>> "secure-sequence" numbers. When the A-bit is set, the choice is between 
>> doing authentication as described in RFC 5880 (bfd.AuthType=[1..5]), or 
>> doing "optimized auth". If "optimized auth" is chosen, bfd.AuthType can 
>> toggle from one of the non-zero values to NULL-auth (whatever non-zero value 
>> is assigned to it) and back.
>> 
>> At the same time, if 'secure-seq-num' is configured as ’true’, the sequence 
>> number is generated as defined by I-D.ietf-bfd-secure-sequence-numbers, and 
>> inserted into the packet. The only question I ask is, if “optimized auth” is 
>> enabled, and when there is a state transition, the packet is “fully” 
>> authenticated by selecting bfd.AuthType as one of the non-zero values (but 
>> not NULL-auth). Do we need to generate a secure sequence number at that 
>> time? Or is it easier/simpler to let it continue generating the secure 
>> sequence number, and not deal with “lost” packets as the session transitions 
>> from bfd.AuthType with a non-zero value and NULL-auth.
> 
>  We should probably stop calling it "secure sequence numbers".  I think that 
> name doesn't help.

We'd talked about this before.  I'm supportive of a late change to the naming 
of the document.

> 
>  Instead, the draft migrated towards just being another Auth Type, but one 
> where the BFD packets are not authenticated.  Instead, the sender is verified 
> to follow a PRNG sequence.  The PRNG is seeded using the secret key and 
> various per-session information.
> 
>  So the Auth Types are "full packet authentication" via SHA, MD5, etc or 
> "verified sender".
> 
>  If the packet isn't authenticated but the sender is verified, then we still 
> can decide that the sender is up.  And it matters a lot less what the rest of 
> the packet contents are.

The procedures in RFC 5880 for the various authentication types discusses what 
is covered by the authentication.  E.g. password doesn't provide a digest for 
any of the packet.

Thus, "Meticulous Keyed ISAAC" is perhaps a reasonable name, and the fact that 
it doesn't cover the entire packet isn't necessary in the naming.  I.e. none of 
the other procedures in their name hint as to what's covered.


> 
>>> Interesting edge choice question: Alan's recent changes permits even 
>>> "simple password" to be a valid mode, but it's probably not something we 
>>> want to operationally support.  In particular, because it does NOT include 
>>> sequence numbers and thus provides zero protection vs. reply during the 
>>> non-optimized path.
>> 
>> Agree. Where do we call this out? In this or in the secure-sequence-number 
>> draft?
> 
>  i would lean towards forbidding "simple password", unless it uses a 
> different password than is used for the stronger authentication methods.  
> Otherwise it leads to the password being exposed.

I'm supportive of that.  What text would you recommend?

>  I would also ask if the ISAAC PRNG is reasonably secure, do we really need 
> to occasionally swap to another Auth Type?

I think this is a matter of question for the generic optimizing procedures.  
For the original proposals where we either had zero authentication going on or 
the latter NULL authentication mechanism with a sequence number, we wanted 
something that proved periodically that the session was actually up.  That 
required temporarily switching to strong authentication and, implicitly, one 
that had sequence numbers to prevent replay attacks.

For Meticulous Keyed ISAAC, we don't have a need for the periodic strong 
authentication. 

Since we now have split motivations, we need text that lets us decide when we 
should periodically use stronger authentication, or not, for staying in the Up 
state.

-- Jeff

> 
>  i.e. what is the reason for switching from ISAAC to SHA1, and then back 
> again?  What are we trying to prove?
> 
>  Alan DeKok.

Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas]

> On Jan 21, 2024, at 11:58 AM, Alan DeKok  wrote:
> 
> On Jan 21, 2024, at 10:43 AM, Jeffrey Haas  wrote:
>> To your final point, ISAAC is reasonably secure for the Up case. However it 
>> doesn’t authenticate the packet contents. 
> 
>  What fields can be modified which *don't* affect the BFD state machine?  
> Most of the fields are mandated to have specific values for this particular 
> session and this particular state.

That's rather the point.  The optimization procedures rely on the fact that 
we're requiring strong authentication as part of the ability to switch to 
something weaker.

For md5/sha1 procedures, the entirety of the PDU is part of the digest.  For 
ISAAC, we're saying, "here's the next sequence number".  We admit in the 
procedures we're not checking the rest of the fields.

A reasonable procedure for an implementation of ISAAC is verifying that the 
contents do not vary.  For the BFD state machinery, any changes to those fields 
is expected to be accomplished through a poll sequence, unless we're going 
Down/AdminDown, in which case we're also wanting strong authentication.


> 
>  i.e. We may not need the full packet to be authenticated in order to 
> maintain an "Up" state.

We've agreed to this, and the logic is covered in the optimizing text.  

> 
>  Perhaps the RX / TX intervals could be modified without detection.  We could 
> update the ISAAC doc to say that these fields need to be cached when ISAAC 
> starts, and can only be changed via an Auth Type which authenticates the full 
> packet content.

I'd not pushed for those details to be spelled out because the only legitimate 
way an implementation can accomplish this is, as above, through a poll sequence.

That said, since ...

> 
>  Doing that would address pretty much all of the issues related to not 
> authenticating the packet.  Either a received packet is byte-for-byte 
> identical to what we expect (plus ISAAC key), or it's not, and we drop it.

... is perhaps a late understanding for you as the expert in ISAAC rather than 
BFD, we certainly can spell it out in a sentence or two in the secure sequence 
numbers document

-- Jeff

Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas]

Alan,

To your final point, ISAAC is reasonably secure for the Up case. However it 
doesn’t authenticate the packet contents. 

Jeff

> On Jan 20, 2024, at 19:45, Alan DeKok  wrote:
> 
> On Jan 19, 2024, at 7:14 PM, Mahesh Jethanandani  
> wrote:
>> In my mind, and my co-authors can correct me if my understanding is 
>> incorrect, I do not see "optimized auth" as a choice between "NULL-auth" and 
>> "secure-sequence" numbers. When the A-bit is set, the choice is between 
>> doing authentication as described in RFC 5880 (bfd.AuthType=[1..5]), or 
>> doing "optimized auth". If "optimized auth" is chosen, bfd.AuthType can 
>> toggle from one of the non-zero values to NULL-auth (whatever non-zero value 
>> is assigned to it) and back.
>> 
>> At the same time, if 'secure-seq-num' is configured as ’true’, the sequence 
>> number is generated as defined by I-D.ietf-bfd-secure-sequence-numbers, and 
>> inserted into the packet. The only question I ask is, if “optimized auth” is 
>> enabled, and when there is a state transition, the packet is “fully” 
>> authenticated by selecting bfd.AuthType as one of the non-zero values (but 
>> not NULL-auth). Do we need to generate a secure sequence number at that 
>> time? Or is it easier/simpler to let it continue generating the secure 
>> sequence number, and not deal with “lost” packets as the session transitions 
>> from bfd.AuthType with a non-zero value and NULL-auth.
> 
>  We should probably stop calling it "secure sequence numbers".  I think that 
> name doesn't help.
> 
>  Instead, the draft migrated towards just being another Auth Type, but one 
> where the BFD packets are not authenticated.  Instead, the sender is verified 
> to follow a PRNG sequence.  The PRNG is seeded using the secret key and 
> various per-session information.
> 
>  So the Auth Types are "full packet authentication" via SHA, MD5, etc or 
> "verified sender".
> 
>  If the packet isn't authenticated but the sender is verified, then we still 
> can decide that the sender is up.  And it matters a lot less what the rest of 
> the packet contents are.
> 
>>> Interesting edge choice question: Alan's recent changes permits even 
>>> "simple password" to be a valid mode, but it's probably not something we 
>>> want to operationally support.  In particular, because it does NOT include 
>>> sequence numbers and thus provides zero protection vs. reply during the 
>>> non-optimized path.
>> 
>> Agree. Where do we call this out? In this or in the secure-sequence-number 
>> draft?
> 
>  i would lean towards forbidding "simple password", unless it uses a 
> different password than is used for the stronger authentication methods.  
> Otherwise it leads to the password being exposed.
> 
>  I would also ask if the ISAAC PRNG is reasonably secure, do we really need 
> to occasionally swap to another Auth Type?
> 
>  i.e. what is the reason for switching from ISAAC to SHA1, and then back 
> again?  What are we trying to prove?
> 
>  Alan DeKok.

Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas]

> On Jan 18, 2024, at 7:26 PM, Mahesh Jethanandani  
> wrote:
>> On Jan 17, 2024, at 5:05 PM, Jeffrey Haas > <mailto:jh...@pfrc.org>> wrote:
> That is a good point. However, and thinking of this from a management 
> perspective, the operator can signal a they want optimized auth. It will up 
> to the implementation to update the bfd.AuthType field as it toggles through 
> the different authentication types. For example, if optimized-auth is set to 
> true, the session could start with no auth, transition to bfd.AuthType=5 as 
> the session is coming up, and then transition to bfd.AuthType=0 after it has 
> reached UP state. 
> 
> Orthogonally, the operator can indicate whether they want to secure the 
> sequence numbers that are included in the BFD packet. It will be up to 
> implementation to decide whether they want to use it when bfd.AuthType is set 
> to a non-zero value, or only use it when bfd.AuthType is set to 0.
> 
> In summary, two new leafs in the YANG model, one boolean leaf for 
> “optimized-auth” and one boolean leaf for “secure-seq-num”.
> 
> If this sounds kosher, I will add text to that effect in the draft.

At the moment, the keychain model is being used for BFD authentication.  It has 
provision for one key set.

Adding new leaves (in a container?) for optimized-auth is one way to do it.  
Having a mode for the optimized auth in a choice for NULL-auth or 
secure-seq-number would do the trick.  There's probably a must condition for 
setting this mode vs. authentication otherwise being set?

Interesting edge choice question: Alan's recent changes permits even "simple 
password" to be a valid mode, but it's probably not something we want to 
operationally support.  In particular, because it does NOT include sequence 
numbers and thus provides zero protection vs. reply during the non-optimized 
path.

>> "configured interval" probably needs to be more specific to this mechanism.  
>> In particular, this is the interval for how long before we retry strong 
>> authentication.
> 
> There is no “strong” vs “weak” authentication, unless I am missing something.
> 
> I have rephrased it to:
> 
> “ Interval at which BFD control packets are retried for authentication”

The tone of language I'm suggesting we find wording for is the non-optimized 
authentication vs. the optimized.  Optimized will currently consist of NULL and 
secure-seq-number.

Both of those new types are authentication.  See below.

>> 
>> 2. Authentication Mode:
>> 
>> The text in this section indicates that there are circumstances where no 
>> authentication (a-bit is off) is permissible.  However, the text then moves 
>> to discuss NULL authentication, which is authentication that still carries 
>> an a-bit, and has contents. This is likely from earlier work prior to 
>> realizing we want some form of anti-replay attack.
>> 
>> I suspect the correct thing to do here is move all text toward discussing 
>> the "non-authenticated" mode as the less encumbered authentication, of which 
>> this document defines the NULL method. 
> 
> Ok. I have changed the text to talk about the value of bfd.AuthType as either 
> a non-zero value or using a zero (NULL) value, even as A-bit is set.

Note that the "NULL" auth type is likely to be not-zero. :-)  Zero is reserved.

>> 3. NULL Auth Type.
>> 
>> The main text here in need of updating is the sequence numbers.  As we've 
>> worked through in the discussions for secure sequence numbers, we want the 
>> sequence numbers to be preserved across authentication mechanisms.
>> 
>> Is the answer to take the text we have in secure sequence numbers covering 
>> this detail and move them to this document?
> 
> Most the text in this document defers to the 
> I-D.ietf-bfd-secure-sequence-numbers draft, and I would not duplicate any 
> text from there in this document.

Ok, we'll review the documents versus each other once edits are in.

Thanks!

-- Jeff

draft-ietf-bfd-stability-10 comments

[Jeffrey Haas]

Authors,

As we finish up work on the authentication features now that secure sequence is 
heading toward completion, it's time to reconcile your draft vs. our current 
learnings in that other work.

The main change that seems appropriate is noting that any meticulous keyed 
authentication mechanism will provide the necessary loss detection as desired 
in this draft.

This draft discusses that in the absence of any other desired mechanism, NULL 
auth, as documented in optimizing authentication, is appropriate.  

The text related to secure sequence numbers needs updating.  But that said, the 
updates are simpler because the mechanism has evolved to using sequence numbers 
the same as the other mechanisms, and providing its benefit in the 
authentication data portion of the PDU.

Could you update the draft vs. the current state of things and refresh it in 
the data tracker?  I suspect we'll rapidly converge on text for last call.

Thanks!

-- Jeff

draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas]

Authors,

Since secure sequence numbers is heading toward WGLC, it's time to refresh this 
document and review it vs. secure sequence numbers, and bfd stability.

-

From Introduction and some confusion about configuration and operational state:

"This document also proposes that all BFD control packets which signal a 
significant change MUST be authenticated if the session's bfd.AuthType is 
non-zero. Other BFD control packets MAY be transmitted and received without the 
A bit set."

There's a bit of semantic confusion here.  bfd.AuthType is what we use as our 
state and what we put in our packet.  And similarly, we're trying to say here 
that "authentication may not be required for some packets".

Part of where this is potentially confusing is that these mechanisms are 
documenting changes from one auth type to the other.

This means we have, leveraging management framework terminology, configuration 
state that represents "start with authentication X, which will use method 1 
that goes into bfd.AuthType and user method 2 which also goes into 
bfd.AuthType".  This also has implications when we have this bit of composite 
configuration with regards to authentication that isn't expected (i.e. NULL 
when secure seq is configured) needs to be addressed.

For operational state, reflecting the active type may be fine, but reflecting 
the hybrid configuration state is also necessary.



One way to work through how to adjust the text is consider what the updates to 
the YANG module might look like.

1.2:
s/a demand model/a demand mode/

"configured interval" probably needs to be more specific to this mechanism.  In 
particular, this is the interval for how long before we retry strong 
authentication.

2. Authentication Mode:

The text in this section indicates that there are circumstances where no 
authentication (a-bit is off) is permissible.  However, the text then moves to 
discuss NULL authentication, which is authentication that still carries an 
a-bit, and has contents. This is likely from earlier work prior to realizing we 
want some form of anti-replay attack.

I suspect the correct thing to do here is move all text toward discussing the 
"non-authenticated" mode as the less encumbered authentication, of which this 
document defines the NULL method. 

The text for secure sequence numbers also is now incorrect since the mechanism 
has evolved.

3. NULL Auth Type.

The main text here in need of updating is the sequence numbers.  As we've 
worked through in the discussions for secure sequence numbers, we want the 
sequence numbers to be preserved across authentication mechanisms.

Is the answer to take the text we have in secure sequence numbers covering this 
detail and move them to this document?

-- Jeff

Re: Publication has been requested for draft-ietf-bfd-unaffiliated-echo-10

[Jeffrey Haas]

Greg,


> On Jan 17, 2024, at 4:43 PM, Greg Mirsky  wrote:
> 
> Hi, Jeff et al.,
> upon more consideration of this draft, the write-up, and the related to the 
> draft BBF liaison 
> , 
> I would propose to include the reference to the liaison in the write-up. 
> Perhaps the following update is acceptable:
> OLD TEXT:
> 5. In discussion over the document's intended status, Greg has expressed an 
> opinion
> that the document should be Experimental rather than Proposed Standard.  As 
> noted 
> in the IETF webpage, "Choosing between Informational and Experimental 
> Status", it is
> the Shepherd's opinion that Experimental is inappropriate.  "The 
> "Experimental" 
> designation typically denotes a specification that is part of some research 
> or 
> development effort".  In this case, implementations are commercially 
> available 
> utilizing mechanisms largely similar to those being codified in this 
> Internet-Draft.  
> NEW TEXT:
> 5. In the discussion over the document's intended status, Greg has noted that 
> the Broadband Forum,
> in its liaison For Information TR-146 and draft-ietf-bfd-unaffiliated-echo 
> (https://datatracker.ietf.org/liaison/1775/ 
> )
> informed the IETF and BFD WG that "In our [Broadband Forum's] opinion, no 
> future standardization
> is required to support TR-146." Greg also expressed an opinion
> that the document should be Experimental rather than Proposed Standard.  As 
> noted 
> in the IETF webpage, "Choosing between Informational and Experimental 
> Status", it is
> Shepherd's opinion is that Experimental is inappropriate.  "The 
> "Experimental" 
> designation typically denotes a specification that is part of some research 
> or 
> development effort".  In this case, implementations are commercially 
> available 
> utilizing mechanisms largely similar to those being codified in this 
> Internet-Draft.  

The BBF liaison is referenced at the mail at the top of the shepherd's report.
That said, I have no issue with the update you suggest and have implemented it 
in the shepherd's report.

Thanks!

-- Jeff

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

[Jeffrey Haas]

Alan,

On Jan 17, 2024, at 11:19 AM, Alan DeKok  wrote:
>  Perhaps then this text.  Which both refers to the other draft, and then also 
> says how such a switch impacts ISAAC.
> 
>  It is RECOMMENDED that implementations periodically use a
>  strong Auth Type for packets which maintain the session in an Up
>  state.  See   target="I-D.ietf-bfd-optimizing-authentication">BFD
>  Authentication for appropriate procedures.

This part is good.


>  The nature of the Meticulous Keyed ISAAC method means that
>  there is no issue with this switch, so long as it is for a small
>  number of packets.  From the point of view of the Meticulous
>  Keyed ISAAC state machine, this switch can be handled similarly
>  to a lost packet.  The state machine simply notices that instead
>  of Sequence Number value being one more than the last value used
>  for ISAAC, it is larger by two.  The ISAAC state machine then
>  calculates the index into the current "page", and uses the found
>  number to validate (or send) the Auth Key.

The fundamental issue here is that once we've selected a seed, we need to 
maintain the ISAAC pages vs. the page base we've selected.

As you note above, if we switch out of ISAAC mode for a few packets, this is no 
different than "lost packets" from the perspective of figuring out what our 
next page should be.  I.e., we should only need to flip a page or two.

Alternatively, if the ISAAC page is maintained with the sequence number no 
matter what on the presumption that we will eventually move back to ISAAC, 
there's no issues.

Noting that we do not have procedure to permit a new seed to be exchanged as 
the limiting factor causing the above is appropriate justification.

-- Jeff

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

[Jeffrey Haas]

Alan,

> On Jan 17, 2024, at 10:18 AM, Alan DeKok  wrote:
> 
>  OK, I've pushed my latest set of changes which address all open concerns.

In that push:

+  It is RECOMMENDED that implementations periodically use a
+  strong Auth Type for packets which maintain the session in an Up
+  state.  We offer no advice here as to how often that signalling
+  should be done.  From a practical point of view, if both parties
+  are using Meticulous Keyed ISAAC and the stream of pseudo-random
+  numbers continues to be correct, then the link must be up, and
+  the other party must be authentic.  The rest of the BFD packet
+  contents then serve to maintain the BFD state machine, which is
+  external to the ISAAC authentication.
+
+  When a system switches from using Meticulous Keyed ISAAC to a
+  different Auth Type method during a session, it MUST do so only
+  for a small number of packets.  It is RECOMMENDED that only one
+  such packet is sent, and the system can then switch back to
+  using Meticulous Keyed ISAAC on the next packet which signals
+  that the session remains in the Up state.
+
+  The nature of the Meticulous Keyed ISAAC method means that
+  there is no issue with this switch.  From the point of view of
+  the Meticulous Keyed ISAAC state machine, this switch can be
+  handled similarly to a lost packet.  The state machine simply
+  notices that instead of Sequence Number value being one more
+  than the last value used for ISAAC, it is larger by two.  The
+  ISAAC state machine then calculates the index into the current
+  "page", and uses the found number to validate (or send) the Auth
+  Key.

I'd recommend this specific text be dropped from the secure sequence number 
document.  The expected procedure for doing the periodic stronger 
authentication is part of the optimizing BFD text.

The test present currently in draft-ietf-bfd-optimizing-authentication-13 is:

"Most packets transmitted on a BFD session are BFD UP packets. Authenticating a 
small subset of these packets, for example, a detect multiplier number of 
packets per configured interval, significantly reduces the computational demand 
for the system while maintaining security of the session across the configured 
interval. A minimum of Detect Multiplier packets MUST be transmitted per 
configured interval. This ensures that the BFD session should see at least one 
authenticated packet during that interval."

If you must have anything in the secure-sequence draft, I suggest no more than:

"It is RECOMMENDED that implementations periodically use a strong Auth Type for 
packets which maintain the session in an Up state.  See [optimizing-bfd] for 
appropriate procedures."

Any tweaks to the procedure can be discussed in the context of that document, 
which will handle not only secure-sequence, but NULL and future options.

-- Jeff

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

[Jeffrey Haas]

Alan,


> On Jan 16, 2024, at 6:47 PM, Alan DeKok  wrote:
> 
> On Jan 16, 2024, at 12:00 PM, Jeffrey Haas  wrote:
>> This means the two scenarios we have during the first transition to ISAAC in 
>> the face of packet loss are:
>> 1. It's on "this" page.
>> 2. It's on the prior page.
> 
>  The simple solution to page issues is to just require that there be no more 
> than 255 lost packets allowed.  That way the current packet is always in the 
> first page of derived ISAAC values.

I've reviewed the relevant text for the "search" and think it's correct.  A 
possible tweak:

  If a calculated key at index "I" does match the Auth Key in
  the packet, then the bfd.MetKeyIsaacRcvAuthIndex field is
  initialized to this value.  THe bfd.MetKeyIsaacRcvAuthBase field
  is then initialized to contain the value of bfd.RcvAuthSeq,
  minus the value of bfd.MetKeyIsaacRcvAuthIndex.  This process
  allows the pseudo-random stream to be re-synchronized in the
  event of lost packets.

Effectively, bfd.MetKeyIsaacRcvAuthBase is the sequence number at which ISAAC 
was first found valid.  This may be a lost packet. Working this into the text 
may help clarify this scenario for implementors.

> 
>  For now, I've largely reworked the text.  The new text is at:  
> https://github.com/mjethanandani/bfd-secure-sequence-numbers/tree/v14-alan

Thanks.  These comments are against the current snapshot at that repository.  
Note that the repository doesn't currently compile so I'm reviewing this via 
the .xml.

A thought about the receiving mode:

Note that in some cases, calculating the expected output of
ISAAC will result in the creation of a new "page" of 256
numbers.  This process will irreversible, and will destroy the
current "page".  As a result, if the generation of a new
output will create a new "page", the receiving party MUST save
a copy of the entire ISAAC state before proceeding with this
calculation.  If the outputs match, then the saved copy can be
discarded, and the new ISAAC state is used.  If the outputs do
not match, then the saved copy MUST be restored, and the
modified copy discarded, or cached for later use.

Similar to our prior discussion about determining the first sequence number of 
synchronizing ISAAC page 0, we can observe that we should only generate the 
next page of the ISAAC table if the received sequence number is in the expected 
range for an Up session.  

This means that on an attack where the attacker is generating a sequence number 
greater than the actual sequence number, we generate at most the next table, 
which will eventually be valid for an Up session.  Those invalid packets will 
not validate, but can at most cause us to do the work "early".

The related requirement would be that we have the "current" page associated 
with the most recently valid sequence number, and one possible pending "next" 
page.

  bfd.MetKeyIsaacRcvKeyKnown
A boolean value which indicates whether or not the system
knows the receive key for the Meticulous Keyed ISAAC Auth Type
method.  The initial value is "false".  This value is changed
to "true" when a party sees that the other party has started
to use the Meticulous Keyed ISAAC Auth Type method.

I think this changes to true the first time we see an _acceptable_ ISAAC 
authenticated PDU.  I.e. we're not permitting the local state to be set and 
spoiled by invalid inputs.



> 
>  The reworked text doesn't address all of your review, but it does go into 
> great detail into how to initialize and operate meticulous keyed ISAAC.  If 
> defines a large number of variables specific to this Auth Type method.  That 
> may seem surprising, but I think that the resulting text was made clearer.
> 
>  The document still needs updates to address the other comments in your 
> review, but it's late here, and the bulk of the work seems to be done.  I'll 
> do more tomorrow, in order to get this off of my plate.

This is very close to done.  Thanks for helping drive this to conclusion. 

-- Jeff

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

[Jeffrey Haas]

Alan,


> On Jan 16, 2024, at 11:47 AM, Alan DeKok  wrote:
> On Jan 16, 2024, at 11:28 AM, Jeffrey Haas  wrote:
>> Option 2:
>> Each side changing to ISAAC authentication knows that lost packets could be 
>> a problem.  The draft says the window we need to keep around is 3*Detect 
>> Mult as part of our receive procedures.  Ergo, as long as the side 
>> transitioning into ISAAC does so only at a sequence number such that it is 
>> within the 3*Detect Mult window, it's reasonable to expect that at least ONE 
>> of the packets is expected to get through to the remote side.
> 
>  Yes.  The nice thing is we know how many packets we lost.  So if we have:
> 
> bfd.AuthSeqKnown = 1, which means:
> 
> bfd.RcvAuthSeq is also known
> 
>  And then when we receive a packet which suddenly contains ISAAC, we have a 
> "packet.AuthSeq" which is the sequence number in the received packet.
> 
>  The difference between packet.AuthSeq and bfd.RcvAuthSeq is the number of 
> "lost" packets.  We can then generate the first ISAAC page, and then simply 
> run through the generated keys 0..255, finding one which matches.
> 
>  Once we've found a matching key, we know it's index.  And we know the 
> sequence number of the packet which was lost.  That sequence number becomes 
> bfd.MetKeyIsaacPageBase, and everything proceeds as if there were no packets 
> lost.

Hm.  I realize what you're saying here.  

It might be okay.

This means the two scenarios we have during the first transition to ISAAC in 
the face of packet loss are:
1. It's on "this" page.
2. It's on the prior page.

Based on the total packets lost and the modulus boundary, you can determine 
whether you even need to try the prior page as well.

So, the negative point here is that you may need to do the expensive 
computation at most twice to get in sync.

That said, it's worth providing text suggesting to implementors "this is an 
issue (here's the fix), try to avoid making the other side do that work by 
holding off switching until you're able to guarantee the other side should get 
it."

> 
>> Side observation1: I no longer remember why RFC 5880 chose the 3* multiplier.
>> 
>> Side observation 2: The Detect Mult itself can go up to 255.  This 
>> pathologically means the session may stay up under hefty packet loss and the 
>> best we can do is do the switch starting at index 0 of a new page and hope 
>> that we sync up.
> 
>  I think it's best to point this out, and demand that for ISAAC, the number 
> of lost packets must always be less than 256.

A cautionary note is the best we can do here.

That said, deployed Detect Mult values tend to be low, and often simply default 
to 3.

> 
>> Another point likely in need of text in the draft is what ISAAC needs to 
>> have done when switching from ISAAC back to strong authentication.  Since 
>> the sequence numbers are kept going regardless of the authentication 
>> mechanism, ISAAC will need to produce new pages when it flips to strong 
>> authentication.  This is to avoid needing to "fast forward" if strong 
>> authentication is left going for a while.
> 
>  Hmm... yes.  I would suggest also that the use of strong authentication 
> should only be for:
> 
> 1) state transitions, in which case we toss all existing ISAAC information.  
> We can generate a new ISAAC seed when the state transitions from down->up 
> again
> 
> 2) we want to send an "up" packet with stronger authentication.  In that 
> case, there are few reasons to send many packets.  Just send one, and swap 
> back to ISAAC.
> 
>  I'm working on updated text, and hope to have a PR out later today.

I believe all of this is simply covered under:
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-13
 
<https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-13>

Once we have our ISAAC text, our roadmap is:
1. secure seq#  WGLC  Depends on: optimizing bfd 
2. bfd stability WGLC. Needs republish. Depends on optimizing bfd
3. optimizing BFD WGLC.  Needs republish. These two proceed as a bundle to IESG.

So, please review the next round of text vs. optimizing bfd.

-- Jeff

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

[Jeffrey Haas]

Alan,


> On Jan 15, 2024, at 7:25 PM, Alan DeKok  wrote:
> On Jan 15, 2024, at 6:22 PM, Jeffrey Haas  wrote:
>> 1. We learn the Seed for this session for the first time.  This somewhat
>> argues we need a bfd.MetKeyIsaacKnown variable.  We require it to not
>> change.  Note that it's critical that we say that we're setting it only
>> after ISAAC authentication has succeeded.
> 
>  That makes sense.
> 
>> 2. We need to generate the ISAAC table from the existing sequence number.
>> It can't simply be sequence 0 because that's attackable.
> 
>  Section 5.1 defines how ISAAC is seeded.  It doesn't use sequence numbers to 
> generate the information.
> 
>  More below.
> 
>> 3. Since we can't set it to zero, and we don't want to generate all
>> intervening ISAAC pages to "catch up" to our random sequence number we
>> started with,
> 
>  But we don't need to "catch up".   We just need to record that we started at 
> an agreed-upon sequence number.

We appear to be in agreement about that, but that's not what the current text 
seems to say.  In particular, the reset to seq#.

> The important bit is that we have a transition from
> 
>bfd.MetKeyIsaacKnown=false
> 
>  to
> 
>bfd.MetKeyIsaacKnown=true
> 
>  When that transition happens, the sequence number in the packet is used as 
> the start point.  That number is the new bfd.MetKeyIsaacPageBase variable you 
> mentioned.
> 
>  Saving that number means that if we get a new sequence number Y, we can do:
> 
>   Auth Key index = Y - bfd.MetKeyIsaacPageBase
> 
>  If that value is smaller than 256, the sequence number is in the current 
> page.  If it's 256 or more, then we need to generate a new page.

We're in agreement.

There is one additional corner case to deal with.  Here's the scenario:

A is transitioning from strong authentication to ISAAC.  
A's seq# mod 256 is 255.  
A's seq# div 0 is "0" - the first page.  This is recorded as the local page 
base for A.
The BFD PDU containing this is sent to B.

The packet to B is lost!

A's next seq# puts it into page 1, index 0.
The BFD PDU containing this is sent to B.

B receives this PDU.  
It notes the seed value, auth ID, and sequence number.
Having received this seed the first time, it treats this seq# as page 0.
Seeking into its first page, index 0, the ISAAC authentication fails.

The issue above illustrates the problem we have with no negotiation between the 
systems about where page 0 exists.  If BFD were reliable, this wouldn't be a 
problem.  We have two likely solutions:

Option 1:
"Page 0" is placed into the ISAAC authentication section in BFD.  Doable, 
crystal clear, and at best noise.  At worst, it provides one additional hint 
for someone who is brute forcing the passwords.

Option 2:
Each side changing to ISAAC authentication knows that lost packets could be a 
problem.  The draft says the window we need to keep around is 3*Detect Mult as 
part of our receive procedures.  Ergo, as long as the side transitioning into 
ISAAC does so only at a sequence number such that it is within the 3*Detect 
Mult window, it's reasonable to expect that at least ONE of the packets is 
expected to get through to the remote side.

Side observation1: I no longer remember why RFC 5880 chose the 3* multiplier.

Side observation 2: The Detect Mult itself can go up to 255.  This 
pathologically means the session may stay up under hefty packet loss and the 
best we can do is do the switch starting at index 0 of a new page and hope that 
we sync up.

-

Another point likely in need of text in the draft is what ISAAC needs to have 
done when switching from ISAAC back to strong authentication.  Since the 
sequence numbers are kept going regardless of the authentication mechanism, 
ISAAC will need to produce new pages when it flips to strong authentication.  
This is to avoid needing to "fast forward" if strong authentication is left 
going for a while.

-- Jeff

Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

[Jeffrey Haas]

Authors,

Feedback on version -12:

: Auth-Key
: 
: This field carries the 32-bit (4 octet) ISAAC output which is associated
: with the Sequence Number. The ISAAC PRNG MUST be configured and initialized
: as given in section TBD, below.

Fill in the TBD.

: While the rest of the contents of the BFD packet are unauthenticated and may 
be
: modified by an attacker, the same is true of stronger Auth Types, such as
: MD5 or SHA1. The Auth Type methods are not designed to prevent such attacks.
: Instead, they are designed to prevent an attacker from spoofing identities,
: and an attacker from artificially keeping a session "Up".

The above is not true.  For MD5/SHA1, the digest is calculated over the
entirety of the PDU.  Changes to PDU contents are thus noted.

Most importantly, the text in section 5 covers what we need to say about
when state changes are done, and only using this for Up.  Thus, simply
delete the above cited paragraph.

5.1 Seeding and Operation of ISAAC:

The substantive portion of my feedback is covered here.  However, I think
we're very close in all other respects.

The text starts with:

: Note that switch to a different AuthType method does not affect the values
: of the bfd.RcvAuthSeq or bfd.XmitAuthSeq variables. The variables MUST
: continue on from their previous values which were using the previous
: AuthType method.

We move to:

: That is, when changing AuthTypes in a session, the current value of the
: bfd.RcvAuthSeq and bfd.XmitAuthSeq variables is used as the initial value(s)
: for the new AuthType.

And finally to:

: The origin of the Seed field is discussed later in this document. For now,
: we note that each time a new Seed is used, the bfd.XmitAuthSeq value MUST be
: set to zero. The Seed MUST be changed when a BFD session transitions into
: the "Up" state. In order to prevent continuous rekeying, the Seed MUST NOT
: be changed while a session is in the "Up" state.

So, twice "don't change it" and once to "set it to zero when we use a seed".

RFC 5880 defines 
:bfd.XmitAuthSeq
: 
:   A 32-bit unsigned integer containing the next sequence number for
:   Keyed MD5 or SHA1 Authentication to be transmitted.  This variable
:   MUST be initialized to a random 32-bit value.

Thus, the intention is that we start with a random value.

If the session is Up with one of the existing types with a known sequence
number, and then we switch to Meticulous Keyed ISAAC, what is likely
happening is:
1. We learn the Seed for this session for the first time.  This somewhat
argues we need a bfd.MetKeyIsaacKnown variable.  We require it to not
change.  Note that it's critical that we say that we're setting it only
after ISAAC authentication has succeeded.
2. We need to generate the ISAAC table from the existing sequence number.
It can't simply be sequence 0 because that's attackable.
3. Since we can't set it to zero, and we don't want to generate all
intervening ISAAC pages to "catch up" to our random sequence number we
started with, we need to treat this somewhat analogously to TCP's initial
sequence number.  How could we do that?
3a. Each ISAAC page is 256 numbers.  Thus, floor(seq# / 256) will give us
the zeroth sequence number for a page.  Store this in a new variable,
bfd.MetKeyIsaacPageBase.
3b. The page-based value in the ISAAC table can thus be selected as the index:
seq# - bfd.MetKeyIsaacPageBase. (With appropriate wrap protection.)

5.2:
: RECOMMENDED to use differnet secret Keys for each Auth Type.

s/differnet/different.

5.3:

: the respective values used by a sending system. For recieving 

s/reieving/receiving/

The procedures here use the input tuple:


I suspect that Secret Key is intended to be able to be selected from a table
of Meticulous Keyed ISAAC based on Auth Key ID?  If so, it's worth adding a
sentence to that effect.  Section 6 covers the necessary procedure in
detail.

6. Meticulous Keyed ISAAC Authentication

: Receipt using Meticulous Keyed ISAAC Authentication
: 
: If the received BFD Control packet does not contain an Authentication
: Section, or the Auth Type is not correct (TBD2 for Meticulous Keyed ISAAC),
: then the received packet MUST be discarded.

This is also TBD1, I believe.

7. IANA Considerations

: Note to RFC Editor: this section may be removed on
: publication as an RFC.

It's traditional to leave in the IANA considerations section in the
document.  The RFC Editor will work with IANA to update the section and the
voicing of the request from a request to what they did.

8.2

: If we recommend different keys, then it is possible for the two keys to be
: configured differently on each side of a BFD lin. For example. 

lin?

-- Jeff


On Wed, Nov 29, 2023 at 05:23:07PM -0800, internet-dra...@ietf.org wrote:
> Internet-Draft draft-ietf-bfd-secure-sequence-numbers-12.txt is now available.
> It is a work item of the Bidirectional Forwarding Detection (BFD) WG of the
> IETF.
> 
>Title:   Secure BFD Sequence Numbers
>Authors: Alan 

Re: Publication has been requested for draft-ietf-bfd-unaffiliated-echo-10

[Jeffrey Haas]

Greg,


> On Jan 15, 2024, at 5:15 PM, Greg Mirsky  wrote:
> For several years I've actively participated in the work at BBF, including 
> the Working Area that published TR-146. I cannot recall that any member 
> company reported TR-146 implementation. Were there any on the BFD mailing 
> list that led to the following summary in the write-up:
> There are multiple implementations that claim some deployment of BBF TR-146 
> implementation behavior.

If you're reading this as "claiming conformance to tr-146", that's not what is 
written here.  Mostly because tr-146 was missing enough detail to make it 
difficult for a BFD implementation to claim actual conformance. That's to a 
great extent what the authors are attempting to rectify.

In terms of the "BFD talking to itself over Echo", which is the implementation 
behavior in question, we can publicly say that the Broadcom implementation is 
certainly in the same family.  Juniper's BFD-Lite feature is also in the same 
family.

Having not asked for a conformance report vs. this document, I'm not pointing 
out other vendors who have similar behaviors.  Certainly I'd encourage others 
with information on their implementations to respond to this thread.

> In the course of discussing this draft, I commented many times that the 
> proposed mechanism doesn't require any action from a BFD system outside of a 
> node that transmits and processes a probe. I suggested that, if there's 
> interest in publishing this draft, it be published as Experimental or 
> Informational, but not a Standard track document. I don't find that point of 
> the discussion reflected in the Shepherd write-up, or affecting the intended 
> status.

I've added the following point to the shepherds report.  Hopefully this 
addresses your concern:

5. In discussion over the document's intended status, Greg has expressed an 
opinion
that the document should be Experimental rather than Proposed Standard.  As 
noted 
in the IETF webpage, "Choosing between Informational and Experimental Status", 
it is
the Shepherd's opinion that Experimental is inappropriate.  "The "Experimental" 
designation typically denotes a specification that is part of some research or 
development effort".  In this case, implementations are commercially available 
utilizing mechanisms largely similar to those being codified in this 
Internet-Draft.  

While the procedures in this draft are purely local (the implementation "talks 
to itself"),
the behavior requires a violation of RFC 5880 
 with regard to Echo procedures only
being available after the Up state has been achieved in Asynchronous mode.  
It is thus the Chairs' opinion that the text permitting the relaxation of that 
requirement is appropriate to standardize for this document, and thus an 
appropriate
change of status requiring an update to RFC 5880 
.

-- Jeff

Re: Publication has been requested for draft-ietf-bfd-unaffiliated-echo-10

[Jeffrey Haas]

With deep apologies to the members of the Working Group for my tardiness,
I've submitted this draft to the IESG.  This is after spending the afternoon
reviewing the discussion to date and verifying the previously raised points
have been addressed.

Thank you in particular to Greg for your careful review on the draft.  The
text benefited greatly from your attention.

-- Jeff


On Mon, Jan 15, 2024 at 12:54:45PM -0800, Jeffrey Haas via Datatracker wrote:
> -UID: 254690  
> 
> Jeffrey Haas has requested publication of draft-ietf-bfd-unaffiliated-echo-10 
> as Proposed Standard on behalf of the BFD working group.
> 
> Please verify the document's state at http

Publication has been requested for draft-ietf-bfd-unaffiliated-echo-10

[Jeffrey Haas via Datatracker]

Jeffrey Haas has requested publication of draft-ietf-bfd-unaffiliated-echo-10 
as Proposed Standard on behalf of the BFD working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/

[nomcom-chair-2...@ietf.org: NomCom 2023 Needs Your Feedback]

[Jeffrey Haas]

The IETF nomcom needs your wisdom to help select members who will take on
the unpaid "management" and leadership roles within the IETF.  Please take a
moment to give them feedback for individuals you may know.

-- Jeff

- Forwarded message from NomCom Chair 2023  
-

Date: Sun, 05 Nov 2023 22:26:13 -0800
From: NomCom Chair 2023 
To: IETF Announcement List 
Subject: NomCom 2023 Needs Your Feedback

Hi,

The NomCom met yesterday decided to keep feedback open until 1200 Friday (CET). 
 We hope to be able to make some decisions on Friday afternoon.

Feedback is welcome in many forms:

 - The web: https://datatracker.ietf.org/nomcom/2023/feedback/

 - Email: nomcom-2...@ietf.org

 - In person: The NomCom will be operating office hours during IETF 118 (see 
below).  Look for NomCom members (we will have an orange dot on our badges).

 - Anonymously/indirectly: We don't have an anonymous feedback system, but any 
member of the IETF community can submit feedback on behalf of another person.  
I am happy to do this for you and have asked that NomCom members also offer to 
accept anonymous feedback.

The NomCom has an office on the Lobby level of the Hilton if you want to come 
in person to provide feedback.  The following times are when the London room is 
currently open (all Prague local time):

Monday: 10:30-12:00, 13:00-16:30, 17:30-18:30
Tuesday: 08:30-09:30, 11:30-12:00, 15:00-15:30, 16:30-18:00
Wednesday: 09:30-10:30, 11:30-12:00, 14:00-14:30, 15:30-16:30
Thursday: 08:30-09:30, 11:30-12:00, 14:30-18:30
Friday: 08:30-12:00

Please knock if the door is closed.  We might be interviewing or talking to 
someone.  If you would like to reserve some of the above time in advance, send 
me a note.  If the room is vacant, send me a note, I might be conducting 
interviews in the Brussels room next door.

Thanks to everyone who has provided feedback already.  The NomCom depends 
greatly on community feedback for making the best decisions.  We treat all 
feedback as confidential.

Thanks,
Martin
nomcom-chair-2...@ietf.org

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

- End forwarded message -

Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

[Jeffrey Haas]

Presuming Rob acks the changes as having addressed his concerns, I believe this 
resolves all lingering IESG comments.

The Working Group should spend a moment to review the changes since it's 
technically a functional change in the YANG model. I believe it's the right 
thing to do.

After letting the draft rest a few days to permit WG review, hopefully the IESG 
will proceed with publication.

Thanks everyone for the work!

-- Jeff


> On Apr 27, 2023, at 11:36 AM, Reshad Rahman 
>  wrote:
> 
> Hi Rob,
> 
> Changes made in rev-15 to simplify the model:
> - Removed the feature for global config, also removed the global enabled leaf
> - At the per-interface level, the enabled leaf doesn't depend on the 
> params-per-interface feature anymore
> - Removed the must statements (since global parms config is not feature 
> dependent anymore)
> 
> Other changes:
> - Changed role from enum to identity (Jeff's suggestion)
> - Updated acknowledgement section
> 
> Regards,
> Reshad.
> 
> 
> 
> Name:draft-ietf-bfd-unsolicited
> Revision:15
> Title:Unsolicited BFD for Sessionless Applications
> Document date:2023-04-27
> Group:bfd
> Pages:18
> URL:
> https://www.ietf.org/archive/id/draft-ietf-bfd-unsolicited-15.txt 
> <https://www.ietf.org/archive/id/draft-ietf-bfd-unsolicited-15.txt>
> Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/ 
> <https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/>
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited 
> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited>
> Diff:   
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unsolicited-15 
> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unsolicited-15>
> 
> 
> On Wednesday, April 19, 2023, 09:31:32 AM EDT, Rob Wilton (rwilton) 
>  wrote:
> 
> 
> Hi Reshad,
> 
>  
> Please see inline …
> 
>  
> From: Reshad Rahman mailto:res...@yahoo.com>> 
> Sent: 19 April 2023 03:38
> To: The IESG mailto:i...@ietf.org>>; Rob Wilton (rwilton) 
> mailto:rwil...@cisco.com>>
> Cc: draft-ietf-bfd-unsolici...@ietf.org 
> <mailto:draft-ietf-bfd-unsolici...@ietf.org>; bfd-cha...@ietf.org 
> <mailto:bfd-cha...@ietf.org>; rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org>; 
> Jeffrey Haas mailto:jh...@pfrc.org>>
> Subject: Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with 
> DISCUSS and COMMENT)
> 
>  
> Hi Rob,
> 
>  
> Thanks for the feedback. And no need to apologize since it took us much 
> longer to respond to your initial comments...
> 
>  
> Please see inline.
> 
>  
> On Tuesday, April 18, 2023, 11:55:03 AM EDT, Rob Wilton (rwilton) 
> mailto:rwil...@cisco.com>> wrote:
> 
>  
>  
> Hi Reshad,
> 
>  
> Apologies for the delay.
> 
>  
> The changes that you have made are sufficient to clear my discuss.
> 
>  
> As a non-discuss (and non-blocking) comment, I do still find this 
> hierarchical configuration to be somewhat complex on two points:
> 
>  
> 1. The configuration is under optional feature statements both at the 
> global level and the per-interface level, and I think that the model would 
> allow neither feature to be specified, in which case the defaults would be 
> ambiguous.  I’m sure that the WG has a good reason for why it is designed the 
> way it is, but I can’t help wondering whether it would make the model 
> cleaner/simpler to require support for the global level configuration, and 
> only have per-interface level configuration under an optional feature.  I.e., 
> if this was done, then logically, there are always well-defined default 
> values without requiring evaluation of the must-statement.
> 
>  Initially when I did the 2 features I was looking for a way to enforce 
> that at least 1 of the 2 features is supported but afaik there's no way in 
> YANG 1.1 to do that. When I addressed your comments about config 
> hierarchy/inheritance, I added the must statements to address that. I did 
> consider removing one of the features but it wasn't clear to me which one 
> should be removed, in that some implementations might prefer having just 
> global config and others would prefer per-interface configuration. But I'm ok 
> with making the global config mandatory (i.e. remove the feature) if there's 
> consensus on that, need to discuss with the co-authors too.
> 
> [Rob Wilton (rwilton)]
> 
> Ack.  The only reason that I went with making supporting global configuration 
> mandatory was that it felt like it should be simpler to implement, and that 
> it

Re: New Version Notification for draft-rvelucha-bfd-offload-yang-05.txt

[Jeffrey Haas]

Reshad,


> On Apr 25, 2023, at 1:53 PM, Reshad Rahman  wrote:
>  Not just the name, but the description. In this case the description 
> says "running in hardware".  Sometimes that line is blurry, e.g. is VPP 
> considered hardware? Should the description instead say something along the 
> times of "running in forwarding plane".
> 
> [...]

>  The BFD implementation I worked on many years ago was distributed to 
> linecards for SH (for scale) but was not "offloaded", in that there was no 
> h/w assist.

A good distinction.  Juniper has implementations that run on the "linecard CPU" 
and some that are built into the ASIC.

I don't know whether it's worth distinguishing the variants in the model.  For 
both of these cases, Juniper calls it "distributed".  However, "running on the 
linecards/forwarding plane" is a reasonable approximation.

-- Jeff

Re: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt

[Jeffrey Haas]

Working Group,

After reviewing draft-07, I believe all pending review comments to date have 
been addressed.  We're waiting on final acknowledgement on one point from Greg 
and then otherwise might proceed with publication.

The shepherd's report is located here for your review:
https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/shepherdwriteup/

-- Jeff


> On Apr 23, 2023, at 10:16 PM,   
> wrote:
> 
> Dear BFD WG,
> 
> 
> 
> A -07 revision of draft-ietf-bfd-unaffiliated-echo has been posted, 
> attempting to address all the WGLC comments.
> 
> The main updates are as below.
> 
> * add a sentence to clarify that this document doesn't change the affiliated 
> BFD Echo function.
> 
> * change the order of section 2 "Updates to RFC 5880" and section 3 
> "Unaffiliated BFD Echo Procedures".
> 
> * add a summary on the Unaffiliated BFD Echo packet fields setting into the 
> end of section "Unaffiliated BFD Echo Procedures".
> 
> * change the text on IP address setting to the same as specified in section 4 
> of RFC 5881.
> 
> * some editorial changes, e.g., s/BFD Unaffiliated Echo packet/Unaffiliated 
> BFD Echo packet/g.
> 
> 
> 
> Best Regards,
> 
> Xiao Min
> 
> Original
> From: internet-dra...@ietf.org 
> To: Raj Boddireddy ;Raj Chetan Boddireddy 
> ;Reshad Rahman ;Ruixue Wang 
> ;Weiqiang Cheng 
> ;肖敏10093570;
> Date: 2023年04月24日 10:09
> Subject: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
> 
> A new version of I-D, draft-ietf-bfd-unaffiliated-echo-07.txt
> has been successfully submitted by Xiao Min and posted to the
> IETF repository.
> 
> Name:draft-ietf-bfd-unaffiliated-echo
> Revision:07
> Title:Unaffiliated BFD Echo
> Document date:2023-04-23
> Group:bfd
> Pages:12
> URL:
> https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-07.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo
> Diff:   
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unaffiliated-echo-07
> 
> Abstract:
>Bidirectional Forwarding Detection (BFD) is a fault detection
>protocol that can quickly determine a communication failure between
>two forwarding engines.  This document proposes a use of the BFD Echo
>where the local system supports BFD but the neighboring system does
>not support BFD.  BFD Async procedures can be executed over the BFD
>Echo port where the neighboring system only loops packets back to the
>local system.
> 
>This document updates RFC 5880.
> 
>   
>  
> 
> 
> The IETF Secretariat
> 
> 
> 

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Jeffrey Haas]

Greg,


> On Apr 22, 2023, at 11:57 AM, Jeffrey Haas  wrote:
>>   Device A performs its initial demultiplexing of a BFD Unaffiliated
>>   Echo session using the source IP address or UDP source port.
>> Am I missing something?
> 
> You are likely not paying sufficient attention to the "initial" word in this
> sentence.
> [...]

> Thus, as per RFC 5880, §6.3:
> :The method of demultiplexing the initial packets (in which Your
> :Discriminator is zero) is application dependent, and is thus outside
> :the scope of this specification.
> 
> and the immediately preceding paragraph:
> 
> :Once the remote end echoes back the local discriminator, all further
> :received packets are demultiplexed based on the Your Discriminator
> :field only (which means that, among other things, the source address
> :field can change or the interface over which the packets are received
> :can change, but the packets will still be associated with the proper
> :session).
> 
> If you believe a reminder of this detail is appropriate in the document,
> consider sending text covering the point.  That said, I'd suggest delaying
> until the authors have integrated the prior comments, which also include
> more clearly labeling the contents of the packets in their text.

Note that the -07 version of the document incorporates additional text 
reinforcing that existing procedures will be used after initial demultiplexing.

Please see if you believe this addresses your concerns.

-- Jeff

Fwd: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Jeffrey Haas]

For whatever reason, Raj's attestation didn't make it into the BFD archives.  
So, a resend.

-- Jeff


> Begin forwarded message:
> 
> From: Raj Chetan Boddireddy 
> Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check
> Date: April 11, 2023 at 9:18:59 AM EDT
> To: Jeffrey Haas , 
> "draft-ietf-bfd-unaffiliated-e...@ietf.org" 
> 
> Cc: rtg-bfd WG 
> 
> I am not aware of any IPR disclosures applicable to this document.
>  
> Thanks & Regards,
> Raj Chetan
>  
> From: Jeffrey Haas mailto:jh...@pfrc.org>>
> Date: Monday, 10 April 2023 at 8:57 PM
> To: draft-ietf-bfd-unaffiliated-e...@ietf.org 
> <mailto:draft-ietf-bfd-unaffiliated-e...@ietf.org> 
>  <mailto:draft-ietf-bfd-unaffiliated-e...@ietf.org>>
> Cc: rtg-bfd WG mailto:rtg-bfd@ietf.org>>
> Subject: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check
> 
> [External Email. Be cautious of content]
> 
> 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo__;!!NEt6yMaO-gk!EjoTAw5NjwurOf5C-nX-pWzjHov0h8Td00L8sN39lR8wetMhrXZfgZTsZS2NfFYGjcUnIkmvwmVB$
>  
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo__;!!NEt6yMaO-gk!EjoTAw5NjwurOf5C-nX-pWzjHov0h8Td00L8sN39lR8wetMhrXZfgZTsZS2NfFYGjcUnIkmvwmVB$>
> 
> Working Group,
> 
> The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has 
> completed.  My judgment is that it has weak, but positive support to proceed 
> to publication.  This isn't atypical of BFD work at this point in the BFD 
> Working Group's life.
> 
> The next steps for the document:
> 
> 1. Please continue to iterate through the issues raised during last call.  I 
> will be summarizing them in the original WGLC thread.  I suspect we can reach 
> conclusion for them shortly.
> 
> 2. Each of the authors needs to make an attestation as to whether they're 
> aware of any additional IPR applicable to this document.  The rest of the 
> Working Group, as per BCP 78/79[1] should also disclose of any applicable IPR 
> if they're aware of it.
> 
> One thing that makes this document particularly interesting is that this work 
> is covered partially under work done in BBF in TR-146.  This will be noted in 
> the shepherd writeup.
> 
> 
> -- Jeff
> 
> [1] 
> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8179.html*section-5.1__;Iw!!NEt6yMaO-gk!EjoTAw5NjwurOf5C-nX-pWzjHov0h8Td00L8sN39lR8wetMhrXZfgZTsZS2NfFYGjcUnIlbXqmPa$
>  
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8179.html*section-5.1__;Iw!!NEt6yMaO-gk!EjoTAw5NjwurOf5C-nX-pWzjHov0h8Td00L8sN39lR8wetMhrXZfgZTsZS2NfFYGjcUnIlbXqmPa$>
> 
> 
> Juniper Business Use Only
> 

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Jeffrey Haas]

Greg,

On Fri, Apr 14, 2023 at 04:05:14PM -0700, Greg Mirsky wrote:
> I am not trying to stop this work but understand what is being standardized
> by this document. So far, I don't see that there's anything that goes
> outside of the BFD system that transmits self-addressed IP/UDP packets. The
> fact that there are implementations using self-addressed IP/UDP packets
> seems like a weak argument for standardization, especially since there's no
> interoperability among network systems to be defined. Of course, that is my
> personal opinion.

At this point I must come to the conclusion that you understand exactly what
is in this document.  You are, of course, welcome to not like it.

If you'd prefer to take your preferences on this as a point of objection to
this being Standard Track rather than Informational, that's a reasonable
point to raise for IESG review.  I'm happy to make note of that in the
shepherd's writeup, if you like.

> On Fri, Apr 14, 2023 at 3:31 PM Jeffrey Haas  wrote:
> > The Discriminator field is used for demux.  Authentication is utilized, if
> > present.
> >
> GIM>> My understanding of the draft in regard to the use of the
> Discriminator (I assume My Discriminator) field is different. Although the
> draft refers to the Discriminators as "demultiplexing fields":
>Once a BFD Unaffiliated Echo session is created on device A, it
>starts sending BFD Unaffiliated Echo packets, which MUST include BFD
>Unaffiliated Echo session demultiplexing fields, such as BFD "Your
>Discriminator" and/or "My Discriminator" defined in [RFC5880].
> it later states that demultiplexing is done based on IP and UDP
> encapsulation:
>Device A performs its initial demultiplexing of a BFD Unaffiliated
>Echo session using the source IP address or UDP source port.
> Am I missing something?

You are likely not paying sufficient attention to the "initial" word in this
sentence.

The procedures in this document run the state machine in a way similar to
other BFD mechanisms that haven't replaced that state machine, such as
S-BFD.

Thus, as per RFC 5880, §6.3:
:The method of demultiplexing the initial packets (in which Your
:Discriminator is zero) is application dependent, and is thus outside
:the scope of this specification.

and the immediately preceding paragraph:

:Once the remote end echoes back the local discriminator, all further
:received packets are demultiplexed based on the Your Discriminator
:field only (which means that, among other things, the source address
:field can change or the interface over which the packets are received
:can change, but the packets will still be associated with the proper
:session).

If you believe a reminder of this detail is appropriate in the document,
consider sending text covering the point.  That said, I'd suggest delaying
until the authors have integrated the prior comments, which also include
more clearly labeling the contents of the packets in their text.

-- Jeff

Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

[Jeffrey Haas]

Zahed,

Oddly enough, it appears that mail from ietf.org delivered one of the two
copies of mail from you in a corrupted form.  This message replies to the
missing piece of your question:

On Tue, Apr 18, 2023 at 12:44:13PM +, Zaheduzzaman Sarker wrote:
> > The environment must be under reasonable operational control to satisfy the
> > scaling of the impacted system.  What words would you prefer to have there
> > instead?  How would those words change if you want to permit this feature to
> > be utilized when the operational environment spans multiple entities, such
> > as at an exchange point (IXP)?
> 
> Calling it something else would not resolve the issue until that “something 
> else” is we defined or described. I have no issue with calling it trustworthy 
> when it is described well to that we can understand it, like you attribute it 
> as – “The environment must be under reasonable operational control to satisfy 
> the scaling of the impacted system”. I suggest we put some descriptive text 
> to explain what is makes the environment trustworthy.

I don't believe that it will be possible to tersely state such a thing,
partially because BFD is simply one element in a deep stack of such
considerations.  As an example, unsecured ARP may be utilized in an IXP
environment.  You can do far more damage by spoofing ARP than you can in
BFD.  Same for discovery components like LLDP.

If you're looking for a particular term of art for such a trustworthy
environment where multiple potentially semi-trustworthy parties are
involved, we'll likely need to have such a thing supplied by current
security practitioners.

>From a general networking standpoint, some properties of such an environment
seem obvious: 
- The network element that can be attacked is expected to be attacked by a
  device one IP hop away. (See GTSM considerations in the draft.)
- Attackers must either be directly connected to the network element or on
  shared media with the network element, thus limiting the set of attackers.
- Layer 2 control mechanisms such as 802.1X may limit the viability of
  attackers to known parties.

In such circumstances, attackers in many circumstances are indistinguisable
from misconfigured or misbehaving parties.  When things go wrong, the IXP
operator will simply chase it down.  It's not like this would be the first
such malfunction.

Active attackers who are breaking into your racks just to mess with you
imply security issues far beyond the scope of this protocol extension.

-- Jeff

Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

[Jeffrey Haas]

Zahed,


> On Apr 18, 2023, at 8:44 AM, Zaheduzzaman Sarker 
>  wrote:
> 
> Hi,
> 
> Thanks for the update. I am afraid I would like to discuss it a bit more so 
> that we understand better the things we are agreeing to.
> 
> Please see inline responses.

> On Thursday, December 15, 2022, 05:39:32 PM EST, Jeffrey Haas 
>  wrote:
>> 
>> It's also not uncommon for implementations to dyanmically adjust their
>> timers based on load within some constraints.  When that's not possible,
>> BFD traffic that becomes unsustainable causes the BFD sessions to start
>> losing packets, which in many cases will cause the session to transition to
>> the Down state - and thus back to slow PDU transmission.
>> 
> Ok I see. Thanks for the pointer. So, there is process of scaling down the 
> number of sessions based of the system load and the way to get there is 
> observed packet loss.

Exactly.  See in particular RFC 5880, §6.8.3.  Short form: A poll sequence is 
the protocol machinery to latch into the new negotiated timers.

Implementations are not required to do such dynamic negotiation, but many 
implementations may do this. See, for example, the use of the term "adaptation" 
in Juniper's manual:
https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/topic-map/bfd.html


> Here the packet loss is not that harmful if I understand correctly.

Packet loss may result in the session going down.  The session going down will 
take the dependent client resource using BFD down as well.

I suspect you'd find the critical detail here is that in such circumstances BFD 
isn't an effective denial-of-service.  If it's over-aggressive, it kills 
itself.  Many implementations also provide for features that keep unstable 
sessions down to avoid repeated flapping.  This is an implementation choice.

> If again my understanding is not correct, then we need mechanism so that we 
> don’t reach to a situation where the system takes the hit due to packet loss. 
> That was not that clear to me.

Hopefully this clarifies the situation.

> The caveat in this draft is related to an unexpected number of BFD sessions

In general, BFD scales by the number of sessions along with the associated 
packet rates.  Operators already must make judgment calls about balancing the 
ability to quickly detect failures with aggressive timers vs. the number of 
sessions the device can support.  Thus, this is not new territory 
operationally.  And similarly, since BFD can negotiate to the least aggressive 
side of a session (RFC 5880, §6.8.7), a well behaving implementation can simply 
decide that unsolicited BFD sessions may be limited by: number of sessions, 
list of acceptable prefixes the sessions come from, and the aggressiveness of 
the timers based on their desire for slow or fast sessions.

-- Jeff

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Jeffrey Haas]

Greg,


> On Apr 14, 2023, at 6:23 PM, Greg Mirsky  wrote:
> 
> Hi Jeff,
> thank you for your kind consideration of the proposal. Indeed, leaving a 
> chunk of memory unchanged is a privacy issue. As I understand the proposal, 
> none of the fields defined in RFC 5880 for the BFD Control message is used 
> for demultiplexing BFD sessions and/or packet validation. Is that correct?

The Discriminator field is used for demux.  Authentication is utilized, if 
present.


> If that is the case, what is the need to use the BFD Control message 
> altogether? And one more step, What is the benefit of using a well-known BFD 
> Echo UDP port number? I believe that using a well-known port increases the 
> security risk rather than bringing any benefits. From what I understand in 
> the application of the mechanism, the sender can use a UDP port number 
> assigned from the dynamic/private range of port numbers. And the payload can 
> be anything, i.e., filled with bit pattern randomly chosen by the Sender. Am 
> I missing something?

Please note you're trying to fight up the slope of the mountain.  This feature 
exists and has long been shipping in various forms already.  Our goal here is 
to try to take the less precise descriptions of the feature and apply some IETF 
rigor to it.  Thanks for helping with that effort.

Recall that the point is that using the BFD echo port in packet loopback mode 
and sending BFD Async packets within it is largely "talking to yourself".  The 
device running this proposal is still running BFD, using as much of the BFD 
Async machinery as makes sense in the mode.  The time fields are, as you note, 
useless.  However, the authentication, discriminator fields let an 
implementation still do demux and authentication without having to write new 
code.

BFD Echo mode was intentionally underspecified to allow implementations to 
decide what they're going to put in the packets.  Implementation considerations 
of BFD Echo have always had the concerns for:
- Is this packet actually sourced by the implementation
- Is spoofing happening
- How do you handle demux when there might be multiple sessions?

The fact that this information is part of the BFD control messages has clearly 
been a convenience to multiple implementations of Echo.

This document simply formalizes one flavor of it.

-- Jeff

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Jeffrey Haas]

Greg,

In general, I think your clarifications are helpful.
The one point I have minor disagreement is "SHOULD be populated/initialized" 
... to what?
One option is "an expected value".
Personally, I'd find "an expected value. A suggested value is ..." and use the 
defaults below.

That said,  I don't have a strong opinion that we must use some magic value.  
My desire is that we avoid unset values being a potential vector for disclosure 
of uninitialized memory.

-- Jeff

> On Apr 12, 2023, at 4:10 PM, Greg Mirsky  wrote:
> 
> Hi Jeff,
> thank you for your response. It seems to me that the values of these fields 
> are implementation specific and don't impact interoperability. If that is 
> correct, then I propose the following updates:
> OLD TEXT:
>Within the BFD Unaffiliated Echo packet, the "Desired Min TX
>Interval" and "Required Min RX Interval" defined in [RFC5880] SHOULD
>be populated with a value of 1 second (1,000,000 microseconds).
>These values, however, are ignored and not used to calculate the
>Detection Time.
> NEW TEXT:
>Within the BFD Unaffiliated Echo packet, the "Desired Min TX
>Interval" and "Required Min RX Interval" defined in [RFC5880], SHOULD
>be initialized before the transmission and MUST be ignored on receipt.
>Furthermore, these values MUST NOT be used to calculate the
>Detection Time.
> 
> OLD TEXT:
>The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set
>to zero.  
> NEW TEXT:
>The "Required Min Echo RX Interval" defined in [RFC5880] SHOULD be set
>before the transmission and MUST be ignored upon receipt.  
> 
> Regards,
> Greg
> 
> 
> On Wed, Apr 12, 2023 at 8:00 AM Jeffrey Haas  <mailto:jh...@pfrc.org>> wrote:
> Greg,
> 
> Flipping the question around somewhat: 
> 
> These portions of the PDU will be serialized onto the wire.
> An implementation could choose values locally to help its own procedures.  
> Perhaps for heuristic tuning of the session.  So, there's argument for "these 
> values are left to the implementation" - or as you note "this value is 
> ignored".  
> 
> What text would YOU want to see present in this draft?
> 
> In the absence of an implementation having an opinion about the behavior for 
> its own purposes, I believe we want some boring "expected" value minimally as 
> implementation advice.  IMO, that's one step nicer than whatever memory noise 
> is left from your allocated buffer that might disclose something unexpected 
> from your implementation internals.  (See various virtualized host 
> environment bugs relating to memory ownership.)
> 
> -- Jeff
> 
> 
> 
> 
>> On Apr 12, 2023, at 10:22 AM, Greg Mirsky > <mailto:gregimir...@gmail.com>> wrote:
>> 
>> Dear, Authors and all,
>> my apologies for the belated comments. I greatly appreciate your 
>> consideration of the notes below:
>> Given that it is stated that the values of "Desired Min TX Interval" and 
>> "Required Min RX Interval" in an Unaffiliated BFD Echo message are ignored, 
>> what do you see as the value of using the normative language in:
>>Within the BFD Unaffiliated Echo packet, the "Desired Min TX
>>Interval" and "Required Min RX Interval" defined in [RFC5880] SHOULD
>>be populated with a value of 1 second (1,000,000 microseconds).
>> As I understand it, the "Required Min Echo RX Interval" value is not used in 
>> the Unaffiliated BFD Echo. If that is the case, what do you see as the value 
>> of requiring it to be zeroed:
>>The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set
>>to zero.  
>> Perhaps stating that the "Required Min Echo RX Interval" value is ignored in 
>> the Unaffiliated BFD Echo is sufficient. WDYT?
>> 
>> Regards,
>> Greg
>> 
>> On Mon, Apr 10, 2023 at 8:27 AM Jeffrey Haas > <mailto:jh...@pfrc.org>> wrote:
>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo 
>> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo>
>> 
>> Working Group,
>> 
>> The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has 
>> completed.  My judgment is that it has weak, but positive support to proceed 
>> to publication.  This isn't atypical of BFD work at this point in the BFD 
>> Working Group's life.  
>> 
>> The next steps for the document:
>> 
>> 1. Please continue to iterate through the issues raised during last call.  I 
&

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Jeffrey Haas]

Greg,


> On Apr 12, 2023, at 1:09 PM, Greg Mirsky  wrote:
> 
> Dear All,
> after reading the document once more, I've realized that I need help with a 
> paragraph in Section 3. Please find my notes in-lined in the original text 
> below under the GIM>> tag:
>Once a BFD Unaffiliated Echo session is created on device A, it
>starts sending BFD Unaffiliated Echo packets, which MUST include BFD
>Unaffiliated Echo session demultiplexing fields, such as BFD "Your
>Discriminator" and/or "My Discriminator" defined in [RFC5880].
> GIM>> It seems like the requirement is not clear on which fields must be 
> initialized by the device A - Your Discriminator, My  Discriminator, or both. 
> Furthermore, these fields are characterized as demultiplexing, although the 
> next sentence states that demultiplexing is based on the source IP address or 
> UDP source port number. If that is the case, what is the role of 
> discriminators in demultiplexing BFD Unaffiliated Echo sessions?

The intent here is that this part of the BFD Async machinery is preserved.  My 
Discriminator is set to the known value, Your Discriminator is zero, and the 
session proceeds with the device talking to itself and resulting in My 
Discriminator and Your Discriminator getting the identical value.

We want to avoid re-stating RFC 5880 procedures on this point.  I realize one 
of your considerations here is likely that some BFD technologies begin by 
having out of band discriminator advertisement.

Would you find it helpful in illustrating the setup in bullet-point fashion as 
Aijun mentioned in prior threads?

>Device A performs its initial demultiplexing of a BFD Unaffiliated
>Echo session using the source IP address or UDP source port.  
> GIM>> Does the source IP address sufficient to demultiplex BFD Unaffiliated 
> Echo sessions? Consider the case that Interface 1 is connected to a broadcast 
> link. Can there be multiple BFD Unaffiliated sessions off Interface 1?
>Device
>A would send BFD Unaffiliated Echo packets with IP destination
>address destined for itself, such as the IP address of interface 1 of
>device A.

My expectation is that there would be a single such session to a given 
destination endpoint simlar to what we see out of the usual BFD 1-hop cases.  
It'd be good to see if this matches the expectations of the authors.

> GIM>> Is "such as" in the sentence above used as "for example" or "that is"?
> GIM>> And a general observation on the terminology. It seems like "device A" 
> is used as a short version of "BFD system hosted on device A". If that is 
> correct, perhaps that can be explained in the Terminology section (although 
> it is missing in the current version of the draft).

Reviewing RFC 5880, that RFC tends to use "the system".  While I find "device 
A/B" to be clear, is it your desire to see "system" to be used for consistency 
with other RFCs?

-- Jeff

Re: New Version Notification for draft-rvelucha-bfd-offload-yang-05.txt

[Jeffrey Haas]

Tom,


> On Apr 13, 2023, at 7:05 AM, t petch  wrote:
> 
> Taking a step back
> 
> On 05/04/2023 10:20, t petch wrote:
>> On 04/04/2023 06:20, Rajaguru Veluchamy (rvelucha) wrote:
>>> Thanks, Tom for review/comments.
>>> 
>>> Version been updated for comments. Can u please check.
> 
> How widely is bfd offload implemented by manufacturers?  I had a look at the 
> Juniper website and find it refers to Distributed BFD running on the Packet 
> Forwarding Engine and Centralized BFD running on the Routing Engine.  Is this 
> what you mean by BFD offload?  (Searching the Juniper website for BFD offload 
> generates thousands of hits none of which seem to be about the offloading of 
> BFD).

This is the same sense as the object in his model.  As usual, the headache with 
such things is often not where it goes in the model, but the gotchas a name 
gives by hidden semantics.

> 
> Who else supports it (such as I could see in publicly available 
> documentation, I am not asking for anything proprietary)?  What other terms 
> are used to reference it?

I'm pretty sure everyone supports it in some flavor.  The lack of visibility to 
see when it's used is a good attribute this model fixes.  The ability to force 
it to be used is the problematic aspect: Sometimes you can configure it, 
sometimes you can't.

The easiest scenario for you to visualize is a system designed with a 
control-plane sourced BFD implementation for multi-hop and MPLS and a broadcom 
linecard implementation of single-hop.  The latter is distributed/offloaded 
whereas the control-plane one is "centralized".

Dealing with the large number of scenarios when it cannot be configured will be 
the bulk of the interesting part of this work.  Do you simply make it a NOP 
when it's not supported?  Do you make it a commit failure?  Etc.

The related possibility is each vendor is permitted to publish a config false 
deviation for scenarios they know it's not possible to configure.

Another option for the working group to consider is that the default behavior 
for this model is to start with "config false" as the baseline expectation and 
to permit vendors to deviate as "config true".  

-- Jeff

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Jeffrey Haas]

Greg,

Flipping the question around somewhat: 

These portions of the PDU will be serialized onto the wire.
An implementation could choose values locally to help its own procedures.  
Perhaps for heuristic tuning of the session.  So, there's argument for "these 
values are left to the implementation" - or as you note "this value is 
ignored".  

What text would YOU want to see present in this draft?

In the absence of an implementation having an opinion about the behavior for 
its own purposes, I believe we want some boring "expected" value minimally as 
implementation advice.  IMO, that's one step nicer than whatever memory noise 
is left from your allocated buffer that might disclose something unexpected 
from your implementation internals.  (See various virtualized host environment 
bugs relating to memory ownership.)

-- Jeff




> On Apr 12, 2023, at 10:22 AM, Greg Mirsky  wrote:
> 
> Dear, Authors and all,
> my apologies for the belated comments. I greatly appreciate your 
> consideration of the notes below:
> Given that it is stated that the values of "Desired Min TX Interval" and 
> "Required Min RX Interval" in an Unaffiliated BFD Echo message are ignored, 
> what do you see as the value of using the normative language in:
>Within the BFD Unaffiliated Echo packet, the "Desired Min TX
>Interval" and "Required Min RX Interval" defined in [RFC5880] SHOULD
>be populated with a value of 1 second (1,000,000 microseconds).
> As I understand it, the "Required Min Echo RX Interval" value is not used in 
> the Unaffiliated BFD Echo. If that is the case, what do you see as the value 
> of requiring it to be zeroed:
>The "Required Min Echo RX Interval" defined in [RFC5880] MUST be set
>to zero.  
> Perhaps stating that the "Required Min Echo RX Interval" value is ignored in 
> the Unaffiliated BFD Echo is sufficient. WDYT?
> 
> Regards,
> Greg
> 
> On Mon, Apr 10, 2023 at 8:27 AM Jeffrey Haas  <mailto:jh...@pfrc.org>> wrote:
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo 
> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo>
> 
> Working Group,
> 
> The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has 
> completed.  My judgment is that it has weak, but positive support to proceed 
> to publication.  This isn't atypical of BFD work at this point in the BFD 
> Working Group's life.  
> 
> The next steps for the document:
> 
> 1. Please continue to iterate through the issues raised during last call.  I 
> will be summarizing them in the original WGLC thread.  I suspect we can reach 
> conclusion for them shortly.
> 
> 2. Each of the authors needs to make an attestation as to whether they're 
> aware of any additional IPR applicable to this document.  The rest of the 
> Working Group, as per BCP 78/79[1] should also disclose of any applicable IPR 
> if they're aware of it.
> 
> One thing that makes this document particularly interesting is that this work 
> is covered partially under work done in BBF in TR-146.  This will be noted in 
> the shepherd writeup.
> 
> 
> -- Jeff
> 
> [1] https://www.rfc-editor.org/rfc/rfc8179.html#section-5.1 
> <https://www.rfc-editor.org/rfc/rfc8179.html#section-5.1>
> 
> 

Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Jeffrey Haas]

Greg,Sorry if the phrasing was confusing. We are looking for any undisclosed ipr. JeffOn Apr 10, 2023, at 9:05 PM, Greg Mirsky  wrote:Hi Jeff,I got confused by the "any additional IPR applicable to this document" in the announcement. AFAIK, there is no IPR disclosure for the draft-cw-bfd-unaffiliated-echo, nor for the draft-ietf-bfd-unaffiliated-echo. Have I missed something?Regards,GregOn Mon, Apr 10, 2023 at 8:27 AM Jeffrey Haas <jh...@pfrc.org> wrote:https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo

Working Group,

The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has completed.  My judgment is that it has weak, but positive support to proceed to publication.  This isn't atypical of BFD work at this point in the BFD Working Group's life.  

The next steps for the document:

1. Please continue to iterate through the issues raised during last call.  I will be summarizing them in the original WGLC thread.  I suspect we can reach conclusion for them shortly.

2. Each of the authors needs to make an attestation as to whether they're aware of any additional IPR applicable to this document.  The rest of the Working Group, as per BCP 78/79[1] should also disclose of any applicable IPR if they're aware of it.

One thing that makes this document particularly interesting is that this work is covered partially under work done in BBF in TR-146.  This will be noted in the shepherd writeup.


-- Jeff

[1] https://www.rfc-editor.org/rfc/rfc8179.html#section-5.1

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Xiao Min,


> On Apr 9, 2023, at 10:42 PM,   
> wrote:
> From: JeffreyHaas 
> 
> "could" isn't one of our RFC 2119 normative terms.  Do you believe "SHOULD" 
> is more appropriate?
> [XM-2]>>> If we would like to use normative term for SA, then that can also 
> apply to DA, suggest s/would/MUST. As Greg pointed out, there may be implicit 
> conflict with RFC 5881 section 4 that says "In particular, the source address 
> SHOULD NOT be part of the subnet bound to the interface over which the BFD 
> Echo packet is being transmitted".
> 
> 

After further thought, I think copying the RFC 5881 advice is perhaps best 
answer.  It provides wisdom that attempts to avoid redirect messages.  However, 
since it's SHOULD NOT rather than MUST NOT, it doesn't make any existing 
implementations non-conformance; e.g. Broadcom.

-- Jeff

draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

[Jeffrey Haas]

https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo

Working Group,

The Working Group Last Call for draft-ietf-bfd-unaffiliated-echo has completed. 
 My judgment is that it has weak, but positive support to proceed to 
publication.  This isn't atypical of BFD work at this point in the BFD Working 
Group's life.  

The next steps for the document:

1. Please continue to iterate through the issues raised during last call.  I 
will be summarizing them in the original WGLC thread.  I suspect we can reach 
conclusion for them shortly.

2. Each of the authors needs to make an attestation as to whether they're aware 
of any additional IPR applicable to this document.  The rest of the Working 
Group, as per BCP 78/79[1] should also disclose of any applicable IPR if 
they're aware of it.

One thing that makes this document particularly interesting is that this work 
is covered partially under work done in BBF in TR-146.  This will be noted in 
the shepherd writeup.


-- Jeff

[1] https://www.rfc-editor.org/rfc/rfc8179.html#section-5.1

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Greg,


> On Apr 7, 2023, at 1:10 PM, Greg Mirsky  wrote:
> On Thu, Apr 6, 2023 at 7:36 AM Jeffrey Haas  <mailto:jh...@pfrc.org>> wrote:
> Greg,
> 
> 
>> On Mar 27, 2023, at 1:40 AM, Greg Mirsky > <mailto:gregimir...@gmail.com>> wrote:
>> 
>> Dear Authors,
>> I read the latest version of the draft. I appreciate your work on improving 
>> its readability. I have several concerns and appreciate your consideration:
>> It appears like the document defines the format of the Echo message. As I 
>> understand the RFC 5880, the format of the Echo message is not specified in 
>> the RFC 5880. It seems like by defining the format in this document, you 
>> affect RFC 5880 compliance of implementations that do support RFC 5880 as it 
>> exists today.
> One way to alternatively view this is we're documenting what one 
> implementation puts in its Echo packets.  This draft does not try to require 
> that all BFD Echo implementations use these procedures.
> GIM>> That is an interesting perspective. If that is the purpose of this 
> specification, then the amount of updates it requires seems excessive. On the 
> other hand, if the group agrees to reflect such intention in the draft, it 
> will alleviate my concern.

The intention for the RFC 5880 changes are to deal with the fact that BFD 
normally expects to be able to send Echo packets only after a session is Up.  
In the case of this document, BFD Async procedures may not happen.

> Furthermore, if that is the position explicitly communicated in the draft, 
> making it Experimental seems like the next logical step. 

I don't think this explicitly follows.

> 
>> The draft, in my opinion, significantly changes the architecture of the BFD, 
>> as it is defined in RFC 5880. I believe that characterizing Echo as a 
>> function stresses its dependency from a BFD mode, Asynchronous and Demand. 
>> The changes proposed in this draft are very extensive and severely affect 
>> the existing architecture of BFD by setting the Echo function on par, 
>> unrelated with the BFD modes.
> 
> Interesting.  My view has been that this mechanism leverages existing BFD 
> Async procedures to avoid trying to completely invent new mechanisms for the 
> unafilliated case.  Where I might have some level of agreement with your 
> point is this "mode" needs to be clearly defined from a configuration 
> standpoint.  For example, how would it manifest in YANG?
> GIM>> It seems that we have different views. I consider the limitation of 
> using the Echo function, specified in RFC 5880, only after the session 
> reaches the Up state as a part of the BFD security mechanism. Personally, I 
> would encourage not to use a well-known UDP port for the type of operation 
> described in the draft. I think it would be more secure to use a port number 
> from the dynamic range. Defining that function as a new optional BFD function 
> without severely updating RFC 5880, in my opinion, is a safer path.

I must give you the same answer we'd have to give to the security ADs: A form 
of this feature has been deployed via BBF TR-146 for quite some time, and 
leverages the BFD Echo port.

At one point, it had been described to me that the motivation for the invention 
of this feature was that it was trivial to enable in some third party chipsets. 
 A quick Google brought me to a manual covering some Broadcom chips.  Some of 
the information in the document is helpful for this discussion:

https://manualzz.com/doc/o/1277tk/broadcom-bcm88690--bcm88800--bcm88480--and-bcm88280-packe...-32.13.5--configuring-bfd-echo

Section 32.13 suggests that dst ip and src ip must be identical and that the 
service will use udp port 3785.

Particularly interesting:
"The Device OAMP supports transmission BFD Echo frames and processing 
looped-back Echo frames. BFD Echo frames are generated by the OAMP as BFD 
Control packets. Upon reception, BFD echo packets are identified at the PMF 
using a specific rule (based on Your-Discriminator), and are sent to the OAMP 
for monitoring through trap mechanisms. The OAMP verifies the applicable 
fields, and monitor reception of the packet to determine LoC."

So, the chipset appears to largely do what we're describing in this document. 
:-)



> 
>> Also, I think that the normative language in the last paragraph of the 
>> Secrity Considerations sections are too soft. Currently used recommendation 
>> level, in my opinion, is insufficient and should be brought to the 
>> requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD 
>> NOT/SHALL NOT/
> 
> I'd recommend that you show the explicit sections you want updated.
> GIM>> Thank you for pointing that out for me. Below are the proposed updates:
> OLD TEXT

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Greg,


> On Apr 7, 2023, at 1:03 PM, Greg Mirsky  wrote:
> Since the feature is intended to be used for single-hop, the source address 
> SHOULD be an address on the shared subnet with the interface of the device 
> that is looping the packets back.  Perhaps it might even be reasonable to 
> require that the source and destination addresses are identical when possible?
> GIM2>> As I understand RFC 5881 , 
> Section 4 recommends not to use an address on the same network as the 
> destination IP address, nor use a link-local IPv6 address as the source IP 
> address for an Echo message:
>In particular, the source address SHOULD NOT be part of the subnet
>bound to the interface over which the BFD Echo packet is being
>transmitted, and it SHOULD NOT be an IPv6 link-local address, unless
>it is known by other means that the remote system will not send
>Redirects.
> Do you think that the normative part of Section 4 is applicable to 
> draft-ietf-bfd-unaffiliated-echo?

Fantastic reference and one I should have looked for.  I believe you're correct 
and that this is an appropriate reference for the unaffiliated draft.

One consideration that is interesting is what address is appropriate to 
configure when a system has exactly one interface?  

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Xiao Min,


> On Apr 7, 2023, at 3:15 AM, xiao.m...@zte.com.cn wrote:
>>> On Apr 6, 2023, at 3:35 AM, >> > >> > wrote:
>> One of the considerations may be whether a IPv6 link local address is 
>> preferable to a global address.  
>> 
>> The only consideration for the draft as it is written is that the address 
>> used as the destination may be looped back by the unaffiliated device.  Link 
>> local helps address the security considerations that impact this feature, 
>> and it might be worth noting that when link local can be used for the use 
>> case that it assists in this point.
> [XM]>>> I checked this with the implementer of this feature, and I'm told 
> setting the DA to a IPv6 link local address doesn't work, because the link 
> local address can't be looped back by the neighboring device.
> 
> 

That's an interesting deficiency.  I will ask Juniper BFD developers if there's 
any similar consideration for our current implementation.

> [XM]>>> I propose the text change as below.
> 
> OLD
> 
> Device A would send BFD Unaffiliated Echo packets with IP destination
>address destined for itself, such as the IP address of interface 1 of
>device A.
> NEW
> 
> Device A would send BFD Unaffiliated Echo packets with IP destination
>address destined for itself, such as the IP address of interface 1 of
>device A. The IP source address of the BFD Unaffiliated Echo packets
>could be identical to the IP destination address or other address 
> provisioned
>on device A.
> 
> 
"could" isn't one of our RFC 2119 normative terms.  Do you believe "SHOULD" is 
more appropriate?

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Aijun,


> On Apr 6, 2023, at 8:53 PM, Aijun Wang  wrote:
>> Providing additional detail to help illustrate the mechanism would be
>> in-scope and perhaps helpful.  Did you have any explicit recommendations for
>> the text?
> [WAJ] How about to refer the style of
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-00#secti
> on-8?

That seems reasonable.  Let's see what the authors say.

>>> Is there any other better style to point out the update to RFC5880?
>> 
>> Unfortunately, this is a common problem for internet-drafts that impact
>> protocol state machinery.  We have either the option of trying to issue a
>> "patch" on the draft, as we're doing here, or do a -bis of the base RFC to
>> more cleanly integrate the changes.
> [WAJ] How about to give the RFC also the version attribute like the draft?
> That is to say, for such "patch" or verbose text update, once the proposed
> draft is published, the updated contents will be incorporated into the base
> RFC automatically(no need to the overall long procedures for the bis
> document), but give its one new version number?  The bit RFC document can be
> labelled with the source that the updates are coming from.
> Maybe this should be discussed in more general scope?
> The final bis RFC document will be more easily referred and readable.

Using IEEE documents as an example, if there is an update to the base document, 
all of the changes are included in it.  If we ever do a RFC 5880-bis, or 
potentially do work to advance BFD to Internet Standard, this might be 
reasonable to do.

For now, the document is consistent with procedures we see in other working 
groups.

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Greg,


> On Mar 27, 2023, at 1:40 AM, Greg Mirsky  wrote:
> 
> Dear Authors,
> I read the latest version of the draft. I appreciate your work on improving 
> its readability. I have several concerns and appreciate your consideration:
> It appears like the document defines the format of the Echo message. As I 
> understand the RFC 5880, the format of the Echo message is not specified in 
> the RFC 5880. It seems like by defining the format in this document, you 
> affect RFC 5880 compliance of implementations that do support RFC 5880 as it 
> exists today.
One way to alternatively view this is we're documenting what one implementation 
puts in its Echo packets.  This draft does not try to require that all BFD Echo 
implementations use these procedures.

> The draft, in my opinion, significantly changes the architecture of the BFD, 
> as it is defined in RFC 5880. I believe that characterizing Echo as a 
> function stresses its dependency from a BFD mode, Asynchronous and Demand. 
> The changes proposed in this draft are very extensive and severely affect the 
> existing architecture of BFD by setting the Echo function on par, unrelated 
> with the BFD modes.

Interesting.  My view has been that this mechanism leverages existing BFD Async 
procedures to avoid trying to completely invent new mechanisms for the 
unafilliated case.  Where I might have some level of agreement with your point 
is this "mode" needs to be clearly defined from a configuration standpoint.  
For example, how would it manifest in YANG?

> Also, I think that the normative language in the last paragraph of the 
> Secrity Considerations sections are too soft. Currently used recommendation 
> level, in my opinion, is insufficient and should be brought to the 
> requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD NOT/SHALL 
> NOT/

I'd recommend that you show the explicit sections you want updated.  Using 
version -06:
- I would not personally suggest that the RECOMMENDED for authentication turn 
into a MUST.  BFD Authentication simply isn't used in enough circumstances to 
try to turn this into the default case, especially when the intent of this 
feature is to deal with systems that don't have a matching BFD on the opposite 
side.
- I not super supportive of the SHOULD NOT for the TTL 255 loop being upgraded 
to SHALL NOT.  This will likely make a number of existing deployments of this 
feature non-conformant.

Please note that I expect to have a repeat of this conversation with the 
security AD during review.  So, your comments are apropos.

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Xiao Min,

Thanks for addressing Greg's comments.  I some additional comment on Greg's 
points:


> On Apr 6, 2023, at 3:35 AM,   
> wrote:
> The draft describes how the destination IP address of the Echo packet is set. 
> Are there any special considerations for selecting IPv6 destination address?
> 
> [XM]>>> The draft currently says "Device A would send BFD Unaffiliated Echo 
> packets with IP destination address destined for itself, such as the IP 
> address of interface 1 of device A". No any special considerations.
> 
> 
One of the considerations may be whether a IPv6 link local address is 
preferable to a global address.  

The only consideration for the draft as it is written is that the address used 
as the destination may be looped back by the unaffiliated device.  Link local 
helps address the security considerations that impact this feature, and it 
might be worth noting that when link local can be used for the use case that it 
assists in this point.

> Also, are there any special considerations for selecting the source IP 
> address for IPv4 and/or IPv6 network?
> 
> [XM]>>> No. If you have any suggestions, please let me know. :)
> 
> 
Since the feature is intended to be used for single-hop, the source address 
SHOULD be an address on the shared subnet with the interface of the device that 
is looping the packets back.  Perhaps it might even be reasonable to require 
that the source and destination addresses are identical when possible?

Where this may complicate procedure is the initial demultiplexing step when the 
session is Down.  Once the session is Up, the Discriminators can be used for 
this purpose.

-- Jeff

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Aijun,


> On Apr 4, 2023, at 5:28 AM, Aijun Wang  wrote:
> From the description of this document, the state machine of local device is
> conformed that described in RFC5880, the main standard parts of this
> document are the contents of related fields within the BFD ECHO Packet. If
> so, I suggested to point out these fields and its value in more explicit
> manner, to facilitate the implementation interoperability.

Perversely, the fact that this mechanism has an implementation "talking to 
itself" means the interoperability considerations are not a primary issue.

Providing additional detail to help illustrate the mechanism would be in-scope 
and perhaps helpful.  Did you have any explicit recommendations for the text?

> Should the section 2(update to RFC5880) be moved afterwards the section
> 3(Unaffiliated BFD Echo Procedures)? 
> And I am worrying that is it easy for the reader/implementer to keep up with
> the updated contents in current manner, because they must compare the two
> documents simultaneously? 

I agree that this would be a helpful change.  It would move the procedure ahead 
of the changes that impact the BFD normative text.

> 
> Is there any other better style to point out the update to RFC5880?

Unfortunately, this is a common problem for internet-drafts that impact 
protocol state machinery.  We have either the option of trying to issue a 
"patch" on the draft, as we're doing here, or do a -bis of the base RFC to more 
cleanly integrate the changes.

Since I think this feature is best documented as an optional extension at this 
time, the "patch" format is our best option.

-- Jeff

Re: Several questions about the draft-ietf-bfd-unaffiliated-echo

[Jeffrey Haas]

Greg,

You may find the official liaison response here in the archives:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/ 
<https://mailarchive.ietf.org/arch/msg/rtg-bfd/vw31qO1UpD7epoZKXT8_obmY64A/>

The contents of that response are:

From: Dave Sinicrope  
<mailto:david.sinicr...@gmail.com;>
To: Jeffrey Haas ,Reshad <mailto:jh...@pfrc.org,Reshad> 
Rahman  <mailto:res...@yahoo.com;>
Cc: Alvaro Retana ,John 
<mailto:aretana.i...@gmail.com,John> Scudder ,Martin 
<mailto:j...@juniper.net,Martin> Vigoureux 
,Dave 
<mailto:martin.vigour...@nokia.com,Dave> Sinicrope 
,Jeffrey 
<mailto:david.sinicr...@gmail.com,Jeffrey> Haas ,Reshad 
<mailto:jh...@pfrc.org,Reshad> Rahman ,Bidirectional 
<mailto:res...@yahoo.com,Bidirectional> Forwarding Detection Discussion 
List  <mailto:rtg-bfd@ietf.org;>
Response Contacts: 
Technical Contacts: 
Purpose: For information

Body: The BBF thanks the IETF BFD WG for informing us of important work on the 
BFD Echo.

We wanted to clarify the "overlapping use case with TR-146". TR-146 leverages 
BFD Echo as a connectivity check mechanism. It does so in a manner where the 
peer does not need a full BFD implementation to echo the packet received. In 
our opinion, no future standardization is required to support TR-146. There is 
no current interest in revising TR-146 to leverage the enhancement of the BFD 
protocol.
We noted in the BBF community that those interested in participating should do 
so in the IETF BFD WG.
 
Sincerely,
 
Lincoln Lavoie,
Broadband Forum Technical Committee Chair


> On Apr 5, 2023, at 7:36 PM, Greg Mirsky  wrote:
> 
> Hi, Dave, Jeff, et al.,
> I was looking for the BFD WG liaison to BBF and its response. I appreciate it 
> if you help me to find out what was the BBF response, as the 
> draft-ietf-bfd-unaffiliated-echo is in the WG LC.
> 
> Thank you in advance.
> 
> Regards,
> Greg
> 
> On Thu, Nov 18, 2021 at 10:05 AM David Sinicrope  <mailto:david.sinicr...@gmail.com>> wrote:
> Hi Jeff, (Sorry for bouncing around email addresses on you… IT challenges 
> this week)
> 
> Thanks for clarifying the assertion concerning BBF interest.  Still, given 
> the statement in the adoption call and the clear references to TR-146 in the 
> draft, it would be a good idea to liaise to BBF, even if brief, and let them 
> know of the draft and its relation to TR-146.  It certainly couldn’t hurt to 
> have open communication with them on the subject.
> 
> Regarding your check with the IESG on the liaison - please proceed as you 
> deem appropriate.  I will say, (and apologies if I’m stating well known 
> details) that typically liaisons don’t need IESG approval.  They are normally 
> crafted/drafted by the WG Chairs, and have some level of review and approval 
> by the WG(s) in question or impacted.  
> 
> I hope this helps find the most expeditious and effective way to proceed.
> Thanks,
> Dave
> 
> On Thu, Nov 18, 2021 at 12:38 Jeffrey Haas  <mailto:jh...@pfrc.org>> wrote:
> David,
> 
> On Thu, Nov 18, 2021 at 05:18:38PM +, David Sinicrope wrote:
> > Sorry, I don't recall our discussion, but then it would have been as long 
> > ago as Singapore in Nov 2019 or before.
> > (Is it possible you spoke with Dave Allan?)
> 
> That's possible!  As I noted in the thread, my notes from that lunch are
> missing.  (I have strong words for Microsoft about their support for Mac
> mail, but that's a different story.)  Whomever I had a conversation with it
> was in a subterranean warren of lunch venues.  Perhaps that will jar
> someone's memory of the venue.
> 
> If you have contact info for Dave Allen I can certainly followup with him.
> 
> > I can say as the BBF Liaison Manager there have been many past claims of
> > BBF interest in IETF work without substantiation.  As a result, it has
> > been key to ensure that any statement of BBF interest in IETF work,
> > especially if made to encourage action in the IETF, be formally supported
> > via a liaison.Searching the Liaison Statements in
> > Datatracker<https://datatracker.ietf.org/liaison/ 
> > <https://datatracker.ietf.org/liaison/>>, I don't see a liaison
> > from either the BBF or IETF related to this work.
> 
> Please note that I don't believe we're asserting that BBF is interested in
> IETF in doing this work for BBF.  And perhaps the easiest answer we'll
> converge to is "remove all mention of BBF".
> 
> That said, throughout the discussion that lead to this draft, it was pointed
> out to the original authors that they were largely covering the TR-146 use
> case.  Minimally, making sure we have a BBF statement regarding the IETF
> work may make sense.
&

Re: Can a BFD session change its source port to facilitate auto recovery

[Jeffrey Haas]

> On Mar 23, 2023, at 3:06 PM, Reshad Rahman  wrote:
> 
>> In practice, what's often seen is that even with full coverage of the paths 
>> that there are end-to-end forwarding faults for various reasons.  In at 
>> least some of these cases it's because BFD is implemented in a layer that 
>> isn't exercising the full data path.  To pick a somewhat vendor neutral 
>> example, consider BFD implemented directly on the line card but not 
>> participating in the layer 3 ECMP load balancer, or at the LAG level not 
>> participating in the layer 2 equivalent.
>  That does seem to be a [in]correct implementation, but besides the 
> point...

Indeed, and a sore point.

As someone who normally prefers to work in control-plane stuff, one of my 
favorite ways to get linecard engineers to turn interesting colors is to ask 
them "what payload can I use to deterministically exercise a given ECMP 
forwarding path for this card, for this set of software, for these chips 
revisions".

-- Jeff

Re: Can a BFD session change its source port to facilitate auto recovery

[Jeffrey Haas]

> On Mar 23, 2023, at 2:17 PM, Reshad Rahman 
>  wrote:
> 
> Hi all,
> 
> +1 to Jeff's comment on not wanting to pretend that everything is fine.
> 
> And if we're running BFD single-hop and BFDoLAG where needed, this is a 
> non-issue right?

Not quite.

In theory, if we had a full set of link tests from A..Z, including exercising 
each LAG member, one would think everything should be fine.  This is an ideal 
basis case.

In practice, what's often seen is that even with full coverage of the paths 
that there are end-to-end forwarding faults for various reasons.  In at least 
some of these cases it's because BFD is implemented in a layer that isn't 
exercising the full data path.  To pick a somewhat vendor neutral example, 
consider BFD implemented directly on the line card but not participating in the 
layer 3 ECMP load balancer, or at the LAG level not participating in the layer 
2 equivalent.

It's for reasons like this that we have discussions about whether it makes 
sense to run single-hop BFD in addition to BFD-on-LAG covering the same link.

(It's also worth reminding the Working Group that these types of discussions 
were a motivation for the LIME Working Group we had some years ago.  It very 
much covered this space, but didn't come to successful outcomes.)

Going back to Abhinav's original question, here are my own observations:

RFC 5880 tells us that once a session is Up, we should demultiplex solely based 
on the Discriminators.  (RFC 5880, §6.3)

RFC 5881, used by RFC 5883 tells us that we MUST NOT change the source ports.  
However, it doesn't provide a lot of justification for the WHY of that.  Given 
the prior point, what is the harm?  Some speculation:

- Even if you MUST demux based on Discriminators, I wouldn't place wagers on 
there being no implementations that aren't looking at the full layer-4 
signature as part of the procedures.  In particular, middlebox steering may get 
in the way.
- It's often necessary for hardware based BFD implementations to put in 
exceptions to rate policers to permit BFD to work.

Speculation aside, changing the source port most likely would work.

Is it a good idea?  Probably not.  

Is it a great tool to try to exercise specific legs of an ECMP?  Almost 
certainly not at high rates.  It'd also be clumsy.

Could you do this with some level of success?  Probably.

Would I want to support debugging issues with this as a vendor?  No.

-- Jeff

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-10

[Jeffrey Haas]

> On Mar 21, 2023, at 5:26 PM, Alan DeKok  wrote:
> 
>>> What if there's no auth method, or auth-type==simple?
>> 
>> Another argument for a separate numbering space.
> 
>  I think that's the best approach.
> 
>>> It just keeps going.  The sequence number isn't used to derive the 32-bit 
>>> Auth-Keys taken from ISAAC.  So wrapping doesn't matter to it.
>> 
>> I may be confused here.
>> 
>> The current sequence number is 2^32 -1, we're on page X for ISAAC.
>> The sequence number wraps to 0 next round.  ISAAC would normally generate 
>> another page.
>> The index into that page is 0 rather than 2^32 at the API level.
> 
>  I think the misconception here is that the ISAAC pages depend on the 
> sequence numbers.  They don't.

I grok it, although I suspect we're speaking past each other.

To save time, what I'd suggest is that if your coauthors agree that discrete 
sequence numbers in BFD per auth type (and auth type details, like seed), write 
up some text that describes that.  It's a change vs. the incompletely specified 
procedures for authentication in the main RFC 5880 text.

Once that's done and verbiage reviewed, I think we may be ready to proceed with 
WGLC.

-- Jeff

Re: Comments on draft-ietf-bfd-secure-sequence-numbers-10

[Jeffrey Haas]

Alan,


> On Mar 21, 2023, at 3:41 PM, Alan DeKok  wrote:
>> If it is the case that the Sequence Number is intended to be a single 
>> continuous
>> space used by both the Meticulous Keyed ISAAC and the stronger authentication
>> while performing state changes, I think we know how this should work.
> 
>  I think we can't do that.  The issue is that the ISAAC method has a 1-1 
> correlation between sequence number and expected output.  The means that each 
> end has to understand where to start from in the sequence.
> 
>  We have a few choices here:
> 
> * use new sequence numbers for ISAAC
>  * always start off at zero
>  * or, start off at some agreed-upon value, perhaps itself derived from ISAAC
> 
> * use sequence numbers taken from a previous auth method
>  * but what if there's no previous auth method, or auth-type==simple?

The "use sequence number taken from previous auth method" is what I had in mind.

A concrete example might explain my thinking.  Let's start with a mechanism 
that has has sequence numbers, such as md5.

The implementation uses md5 authentication in meticulous mode to bring up the 
session.  It reaches sequence number 20 before deciding it wants to switch to 
ISAAC mode.  Logically, one way to think about this is the state at this point 
is:
For a given session
- For the meticulous md5 auth type
- For a specific meticulous md5 auth key id
- There's a sequence number (bfd.XmitAuthSeq)

One headache is the authseq is permitted (encouraged) to be non-zero:
   bfd.XmitAuthSeq

  A 32-bit unsigned integer containing the next sequence number for
  Keyed MD5 or SHA1 Authentication to be transmitted.  This variable
  MUST be initialized to a random 32-bit value.
(RFC 5880, §6.8.1)

Existing BFD procedures aren't terribly well written when authentication needs 
to change.  (One of our headaches for the optimizing authentication draft.)  
RFC 5880 §6.7.1 handwaves a lot of the detail in enabling and disabling 
authentication and is pretty much silent about changing stuff in the middle.  
So, we're partially making decisions about how such things behave.

If the state we're keeping isn't only the simple boring scalar variable that's 
in the document (bfd.XmitAuthSeq) and is rather the per-session, per-type, we 
can envision maintaining  sequence numbers separately for each method.  That's 
pretty straight forward.  This makes our state for ISAAC:

For a given session
- For the meticulous ISAAC auth type
- For a specific meticulous ISAAC auth key id
- For a specific seed
- There's a sequence number (bfd.XmitAuthSeq)


However, if we do so, this means that our packet acceptance criteria gains 
complexity.  We're expected to verify that our received authseq is within the 
expected range allowing for dropped packets. (RFC 5880, §6.7.3)  It's still 
easy to envision we keep that acceptable window per auth method.  Keeping track 
of those windows and whether we're missing a packet or not based on 
authentication method is doable, but gets messier.  This impacts the 
draft-ietf-bfd-stability draft a bit.

None of these things are impossible.  It does, however, mean we need more text 
covering that detail.  (It's just text.)

By contrast, if we used a single shared authseq, we change none of the above 
protocol complexity.  If the number is 20 for md5 and the next packet is ISAAC 
with sequence number 21 and seed-x, the implementation still computes the ISAAC 
table and indexes into 21.  Basically, it has skipped 0..20.

Where this gets ugly is if the protocol runs without ISAAC for some time.  
Let's say that we got to 513.  We'd need to know that last page we computed for 
ISAAC was 0..255, compute the next two iteratively, then index into the 513 
entry.  Still possibly "cheap" given the compute time for pages, but clearly 
the setup for a far uglier case where the skip is so far out that we don't 
compute the page in time to catch packets before they drop.

So, the tension here is simplicity vs. the majority of the existing procedure 
and burning unexpected time for ISAAC.

I'm fine with either answer, and I suspect your inclination is keeping the 
separate sequence number spaces and updating the rest of the procedure to 
clarify for that.  It'd be good to hear from the other authors as well on this 
point.

>> 
>> Since Meticulous Keyed ISAAC is only expected to be done in the Up state 
>> after
>> the optimized procedures, the sequence number should be non-zero.
> 
>  What if there's no auth method, or auth-type==simple?

Another argument for a separate numbering space.


>> Clearly the mechanism won't work great if so great a time passes that the
>> sequence numbers have turned through multiple pages.  This isn't the 
>> expected or
>> desired behavior since optimizing authentication procedures are there solely 
>> for
>> securing state changes.  However, those consequences should likely be 
>> mentioned.
> 
>  I think all of this can be avoided if we just restart the sequence 

Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-10.txt

[Jeffrey Haas]

Alan,


> On Mar 9, 2023, at 3:02 PM, Alan DeKok  wrote:
>  One question is whether the document should contain sample code.  ISAAC 
> isn't trivial, and it's easy to get it wrong.  The GitHub repo includes 
> source code, but is that enough?

I would avoid re-stating or otherwise including this in the BFD specification.  
The primary thing we're looking for is a stable external reference.

-- Jeff

Comments on draft-ietf-bfd-secure-sequence-numbers-10

[Jeffrey Haas]

Authors,

Thank you for the substantive update on this draft.  I think we're most of
the way there!

Aside from my questions about the auth seq number space being shared between the
different modes (ISAAC vs. strong), my comments are largely editorial.

Comments below in the idnits numbered document:


112 3.  Meticulous Keyed ISAAC
[...]

150Sequence Number

152   The sequence number for this packet.  For Meticulous Keyed ISAAC
153   Authentication, this value is incremented for each successive
154   packet transmitted for a session.  This provides protection
155   against replay attacks.

I believe this sequence number is effectively per-seed.  Perhaps say something
about that here?

180While the rest of the contents of the BFD packet are unauthenticated
181and may be modified by an attacker, the same is true of stronger Auth
182Types, such as MD5 or SHA1.  The Auth Type methods are not designed
183to prevent such attacks.  Instead, they are designed to prevent an
184attacker from spoofing identities, and an attacker from artificially
185keeping a session "Up".

This detail is incorrect for the MD5/SHA1 mechanisms.  They are computed over
the entire BFD Control packet.  (RFC 5880, §6.7.3)  

It's reasonable to call out that the BFD Control packet containing the
Meticulous Keyed ISAAC authentication mechanism that no authentication is done
over the packet.  This is no different than the Simple Password mechanism in
terms of authentication over the packet, but clearly significantly better in
terms of detection of modification due to the randomness of the authkey.

187 4.  Operation

[...]

201Note that since the packets are not signed with this authentication
202type, the Meticulous Keyed ISAAC method MUST NOT be used to signal
203BFD state changes.  For BFD state changes, and a more optimized way
204to authenticate packets, please refer to BFD Authentication
205[I-D.ietf-bfd-optimizing-authentication].  Instead, the packets
206containing Meticulous Keyed ISAAC are only a signal that the sending
207party is still alive, and that the sending party is authentic.  That
208is, these Auth Type methods must only be used when
209bfd.SessionState=Up, and the State (Sta) field equals 3 (Up).

A detail that needs to be clarified in the interactions between these two drafts
is keeping track of Sequence Numbers between the competing mechanisms.

If it is the case that the Sequence Number is intended to be a single continuous
space used by both the Meticulous Keyed ISAAC and the stronger authentication
while performing state changes, I think we know how this should work.

Mostly what is needed is mention of this use of the same sequence numbers.
Review of the optimizing authentication procedures for this integration is also
probably wise.

211 4.1.  Seeding and Operation of ISAAC
[...]

216The origin of the Seed field is discussed later in this document.
217For now, we note that each time a new Seed is used, the
218bfd.XmitAuthSeq value MUST be set to zero.  The Seed MUST be changed
219when a BFD session transitions into the "Up" state.  In order to
220prevent continuous rekeying, the Seed MUST NOT be changed while a
221session is in the "Up" state.

Here is where the sequence numbers would need to be coordinated.

Since Meticulous Keyed ISAAC is only expected to be done in the Up state after
the optimized procedures, the sequence number should be non-zero.  I think the
primary consequence is that when ISAAC procedures kick in for a particular seed,
it could be necessary to generate some number of next-pages to permit index into
the space.

Clearly the mechanism won't work great if so great a time passes that the
sequence numbers have turned through multiple pages.  This isn't the expected or
desired behavior since optimizing authentication procedures are there solely for
securing state changes.  However, those consequences should likely be mentioned.

248The Sequence Number can increment without bounds, though it can wrap
249once it reaches the limit of the 32-bit counter field.  ISAAC has a
250cycle length of 2^8287, so there is no issue with using more than
2512^32 values from it.

For the case where the sequence number wraps, what's the expected ISAAC
behavior?  Should it to be to regenerate the page for the supplied credentials
back at sequence number zero?  (I expect the usual security AD commentary about
this opening things up to replay attacks, but also expect to point them to the
usual 2^32 is a Very Big Number point.)

The comment below suggests this is a reset.

253The result of the above operation is an infinite series of numbers
254which are unguessable, and which can be used to authenticate the
255sending party.

Depending on the 

Re: Comments on draft-ietf-bfd-unaffiliated-echo-05

[Jeffrey Haas]

[resend with correct draft address]

Authors,

Some comments on version -05:

16  Abstract

18 Bidirectional Forwarding Detection (BFD) is a fault detection
19 protocol that can quickly determine a communication failure between
20 two forwarding engines.  This document proposes a use of the BFD Echo
21 where the local system supports BFD but the neighboring system does
22 not support BFD.

It would be good in the abstract to discuss the core idea of this mechanism:
BFD Async procedures can be executed over the BFD Echo port where the remote
system only loops packets back to the local system.

The procedures discussed below cover this, but it takes some time to understand
what the intent is.


73  1.  Introduction
[...]

86 BFD defines Asynchronous and Demand modes to satisfy various
87 deployment scenarios.  It also supports an Echo function to reduce
88 the device requirement for BFD.  When the Echo function is activated,
89 the local system sends BFD Echo packets and the remote system loops
90 back the received Echo packets through the forwarding path.  If
91 several consecutive BFD Echo packets are not received by the local
92 system, then the BFD session is declared to be Down.

It would be appropriate to reference RFC 5880, section 5 here.  "The payload of
a BFD Echo packet is a local matter".  This draft, on the other hand, specifies
the contents of the Echo packets and what to do with them.

94 When using BFD Echo function, there are two typical scenarios as
95 below:

97 *  Full BFD protocol capability with affiliated Echo function.  This
98scenario requires both the local device and the neighboring device
99to support the full BFD protocol.

101*  BFD Echo-Only method without full BFD protocol capability.  This
102   scenario requires only the local device to support sending and
103   demultiplexing BFD Control packets.

The bullet point above is a good place to discuss that the BFD Control packets
are sent over the BFD Echo port, but that the BFD Async procedures are used with
the modifications described in this document.


266 3.  Unaffiliated BFD Echo Procedures

[...]

288To rapidly detect any IP forwarding faults between device A and
289device B, a BFD Echo session MUST be created at device A, and the BFD

I would remove the "To rapidly detect" clause before the comma and replace it
with "For unaffiliated echo,".  The current wording seems to suggest this
procedure is the only way to detect forwarding faults.

Perhaps also change "session MUST be created" with "session is created".  

290Echo session MUST follow the BFD state machine defined in Section 6.2
291of [RFC5880], except that the received state is not sent but echoed
292from the remote system, and AdminDown state is ruled out because
293AdminDown effectively means removal of BFD Echo session.  In this

Perhaps:
"from the remote system.  BFD Unaffiliated Echo does not use the AdminDown
state."

293In this
294case, although BFD Echo packets are transmitted with destination UDP
295port 3785 as defined in [RFC5881], the BFD Echo packets sent by
296device A are BFD Control packets too,

Perhaps:
"BFD Control packets are transmitted and received as BFD Echo packets using
destination UDP port 3785, as defined in [RFC5881]."

296the looped BFD Echo packets
297back from device B would drive BFD state change at device A,
298substituting the BFD Control packets sent from the BFD peer.  Also
299note that when device A receives looped BFD Control packets, the
300validation procedures of [RFC5880] are used.

Perhaps:
"The procedures for BFD Async sessions are executed for the looped BFD Control
packets as per [RFC5880], including validation and authentication."

302Once a BFD Echo session is created at device A, it starts sending BFD
303Echo packets, which MUST include BFD Echo session demultiplexing
304fields, such as BFD "Your Discriminator" defined in [RFC5880] (BFD
305"My Discriminator" can be set to 0 to avoid confusion), except for

Why would My Discriminator be 0?  A local value should be chosen to distinguish
individual sessions.  This is for a few reasons:
- Demultiplexing for sessions that are Up should happen solely based on
  discriminators, if possible.
- RFC 5880, Section 6.8.6 says:
  :   If the My Discriminator field is zero, the packet MUST be
  :   discarded.


306BFD "Your Discriminator", device A can also use IP source address or
307UDP source port to demultiplex BFD Echo session, or there is only one
308BFD Echo session running at device A.

Perhaps:
Device A performs its initial demultiplexing of a BFD Unaffiliated session using
the source IP address or UDP source 

Comments on draft-ietf-bfd-unaffiliated-echo-05

[Jeffrey Haas]

Authors,

Some comments on version -05:

16  Abstract

18 Bidirectional Forwarding Detection (BFD) is a fault detection
19 protocol that can quickly determine a communication failure between
20 two forwarding engines.  This document proposes a use of the BFD Echo
21 where the local system supports BFD but the neighboring system does
22 not support BFD.

It would be good in the abstract to discuss the core idea of this mechanism:
BFD Async procedures can be executed over the BFD Echo port where the remote
system only loops packets back to the local system.

The procedures discussed below cover this, but it takes some time to understand
what the intent is.


73  1.  Introduction
[...]

86 BFD defines Asynchronous and Demand modes to satisfy various
87 deployment scenarios.  It also supports an Echo function to reduce
88 the device requirement for BFD.  When the Echo function is activated,
89 the local system sends BFD Echo packets and the remote system loops
90 back the received Echo packets through the forwarding path.  If
91 several consecutive BFD Echo packets are not received by the local
92 system, then the BFD session is declared to be Down.

It would be appropriate to reference RFC 5880, section 5 here.  "The payload of
a BFD Echo packet is a local matter".  This draft, on the other hand, specifies
the contents of the Echo packets and what to do with them.

94 When using BFD Echo function, there are two typical scenarios as
95 below:

97 *  Full BFD protocol capability with affiliated Echo function.  This
98scenario requires both the local device and the neighboring device
99to support the full BFD protocol.

101*  BFD Echo-Only method without full BFD protocol capability.  This
102   scenario requires only the local device to support sending and
103   demultiplexing BFD Control packets.

The bullet point above is a good place to discuss that the BFD Control packets
are sent over the BFD Echo port, but that the BFD Async procedures are used with
the modifications described in this document.


266 3.  Unaffiliated BFD Echo Procedures

[...]

288To rapidly detect any IP forwarding faults between device A and
289device B, a BFD Echo session MUST be created at device A, and the BFD

I would remove the "To rapidly detect" clause before the comma and replace it
with "For unaffiliated echo,".  The current wording seems to suggest this
procedure is the only way to detect forwarding faults.

Perhaps also change "session MUST be created" with "session is created".  

290Echo session MUST follow the BFD state machine defined in Section 6.2
291of [RFC5880], except that the received state is not sent but echoed
292from the remote system, and AdminDown state is ruled out because
293AdminDown effectively means removal of BFD Echo session.  In this

Perhaps:
"from the remote system.  BFD Unaffiliated Echo does not use the AdminDown
state."

293In this
294case, although BFD Echo packets are transmitted with destination UDP
295port 3785 as defined in [RFC5881], the BFD Echo packets sent by
296device A are BFD Control packets too,

Perhaps:
"BFD Control packets are transmitted and received as BFD Echo packets using
destination UDP port 3785, as defined in [RFC5881]."

296the looped BFD Echo packets
297back from device B would drive BFD state change at device A,
298substituting the BFD Control packets sent from the BFD peer.  Also
299note that when device A receives looped BFD Control packets, the
300validation procedures of [RFC5880] are used.

Perhaps:
"The procedures for BFD Async sessions are executed for the looped BFD Control
packets as per [RFC5880], including validation and authentication."

302Once a BFD Echo session is created at device A, it starts sending BFD
303Echo packets, which MUST include BFD Echo session demultiplexing
304fields, such as BFD "Your Discriminator" defined in [RFC5880] (BFD
305"My Discriminator" can be set to 0 to avoid confusion), except for

Why would My Discriminator be 0?  A local value should be chosen to distinguish
individual sessions.  This is for a few reasons:
- Demultiplexing for sessions that are Up should happen solely based on
  discriminators, if possible.
- RFC 5880, Section 6.8.6 says:
  :   If the My Discriminator field is zero, the packet MUST be
  :   discarded.


306BFD "Your Discriminator", device A can also use IP source address or
307UDP source port to demultiplex BFD Echo session, or there is only one
308BFD Echo session running at device A.

Perhaps:
Device A performs its initial demultiplexing of a BFD Unaffiliated session using
the source IP address or UDP source port.

308Device A would send 

Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Note that the draft is currently expired and will be refreshed when the IETF 
116 restrictions permit that to happen.

-- Jeff


> On Mar 21, 2023, at 12:02 PM, Jeffrey Haas  wrote:
> 
> Working Group,
> 
> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/
> 
> The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.
> 
> The draft, in my opinion, is in fairly good shape.  However, since it
> functions via looping packets back to itself and trying to exercise the
> normal RFC 5880 state machine behaviors to a large extent, the draft could
> use very high scrutiny for several matters:
> 
> - Does the state machine behave appropriately at all stages?
> - Are the descriptions of the values of the BFD fields clear in all cases?
> 
> Please supply the authors and the Working Group with your feedback.
> 
> The intended finish date for this WGLC is 7 April, 2023.  This is one week
> after the end of IETF 116.
> 
> Note that Reshad is an author on the draft, so I'll be handling the full set
> of review and shepherding work.
> 
> -- Jeff

WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas]

Working Group,

https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/05/

The authors of draft-ietf-bfd-unaffiliated-echo have requested WGLC.

The draft, in my opinion, is in fairly good shape.  However, since it
functions via looping packets back to itself and trying to exercise the
normal RFC 5880 state machine behaviors to a large extent, the draft could
use very high scrutiny for several matters:

- Does the state machine behave appropriately at all stages?
- Are the descriptions of the values of the BFD fields clear in all cases?

Please supply the authors and the Working Group with your feedback.

The intended finish date for this WGLC is 7 April, 2023.  This is one week
after the end of IETF 116.

Note that Reshad is an author on the draft, so I'll be handling the full set
of review and shepherding work.

-- Jeff

Re: Alvaro Retana's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

[Jeffrey Haas]

> On Mar 21, 2023, at 7:18 AM, Alvaro Retana  wrote:
> 
> 
> Ok -- then, why even mention multihop?  The text should either
> indicate that the document only applies to single hop, or explain the
> security risks.

[...]

> The comparison then seems out of place and unnecessary.
> 
> 
> Note that these are non-blocking comments.  I trust that you will do
> the right thing to avoid unnecessary confusion.

I don't think we're on the same page regarding "unnecessary confusion".

BFD features and profiles have different flavors of applicability.  It's been 
practice to mention items specifically to say "and this is out of scope".  
Examples of this regularly include Echo and Demand modes.  For this document, 
multihop is out of scope, and explicitly mentioned so.  This prevents the 
"well, this looks like it could work for multihop" that will inevitably be 
asked next round.

The same goes for S-BFD.  "Why don't you use this instead?"  Well, here's why.

Yes, these are non-blocking comments.  The explanation is for the archive and 
for the remainder of the IESG review process.

If you have specific suggestions that make this more clear _for you_, I'm sure 
the authors would be happy to consider such edits.  

-- Jeff

Re: Alvaro Retana's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

[Jeffrey Haas]

Alvaro,

On Dec 14, 2022, at 10:11 AM, Alvaro Retana via Datatracker  
wrote:
> 
> 
> --
> COMMENT:
> --
> 
> (1) The Introduction makes several claims that must be developed further or
> eliminated to avoid further confusion.
> 
> (1a)
> 
> 131The procedure described in this document could be applied to BFD 
> for
> 132Multihop paths [RFC5883].  However, because of security risks, this
> 133document applies only to BFD for single IP hops [RFC5881].
> 
> At first glance, I didn't see anything in rfc5883 that would prevent a node in
> the passive role from following this specification.  What am I missing?
> 
> Aren't the security risks already addressed in rfc5883?

The operational difference is that if you can't use GTSM, you're enabling BFD 
sessions to be created multiple hops away, potentially with low requirements 
for authentication.  In the absence of authentication, BFD sessions can be 
created with asymmetric parameters such that an attacker can keep a session 
open with a small number of BFD packets while the system running the 
unsolicited procedures was busy sending packets at a much higher rate.

BFD procedures will prevent a session from moving to Up via blind packet 
injection due to Discriminators needing to be exchanged.

The possibility thus exists to utilize unsolicited BFD as a packet 
amplification attack.

Thus, it's not a generally good use case.

Strong authentication, as noted, may permit this to be a useful feature.  
However, it's not the expected (nor deployed) use case.


> 
> (1b)
> 
> 135Compared to the "Seamless BFD" [RFC7880], this proposal involves 
> only
> 136minor procedural enhancements to the widely deployed BFD itself.
> 137Thus we believe that this proposal is inherently simpler in the
> 138protocol itself and deployment.  As an example, it does not require
> 139the exchange of BFD discriminators over an out-of-band channel 
> before
> 140BFD session bring-up.
> 
> Given that this proposal claims to be better (or at least simpler) than S-BFD,
> what should an operator consider when deciding which to use?  Are they 
> covering
> similar use cases?  If this is so much better, why is rfc7880 not deprecated?

S-BFD is a fancy ping mechanism.  Unsolicited BFD permits both sides to 
participate in actively testing the connection.  Different use cases.

> 
> 
> 468*  Deploy the feature only in certain "trustworthy" environment,
> 469   e.g., at an IXP, or between a provider and its customers.
> 
> If this measure is mandatory, please expand on what a ""trustworthy"
> environment" is.

It's hard to believe this is a serious comment.  "You'll know it when you see 
it?"  

That said, what words would you prefer to see here?

-- Jeff

Re: [Technical Errata Reported] RFC5880 (7240)

[Jeffrey Haas]

John,

The text below covers what I'd hoped to accomplish with the errata.  Thanks.

At some point BFD should consider if we feel like doing the work to move the 
base documents to Internet Standard.  

-- Jeff


> On Mar 6, 2023, at 9:42 AM, John Scudder  wrote:
> 
> Once again, we seem to have come close to something resembling a consensus on 
> this point, other than needing some new text to agree on. To spur discussion, 
> I’ve updated the erratum, but not verified it, pending discussion of my 
> suggested text. I’d verify it as “hold for document update”.
> 
> Please weigh in, within the next few days, if you want to express any further 
> opinions. Either “good grief, end the pain and verify it already” or “no John 
> that’s wrong, please change it as follows” would be helpful.
> 
> I’ve pasted the updated version below.
> 
> —John
> 
> 
> Section 6.8.1 says:
> 
>   bfd.LocalDiag
> 
>  The diagnostic code specifying the reason for the most recent
>  change in the local session state.  This MUST be initialized to
>  zero (No Diagnostic).
> 
> It should say:
> 
> No proposed changes are offered here. See the notes for further discussion.
> 
> Notes:
> 
> RFC 5880 at various points calls out setting the value of bfd.LocalDiag as 
> part of state transitions. The text defining the feature calls for it to be 
> initialized to zero. Discussion on the WG mailing list following the filing 
> of the initial version of this erratum revealed two things:
> 
> First, the text of the RFC is correct, complete, and reflects the authors’ 
> intention at the time of writing, which really WAS that the value should only 
> be initialized to zero but not reset to zero at any other time. 
> 
> Second, by not emphasizing this point, the spec although formally speaking 
> unambiguous, left space for implementors to exercise their intuitions and 
> creativity. As a result, several implementations are reported to reset this 
> value to zero when the session transitions back to Up.
> 
> The discussion is archived at 
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/yEOx2LTO51zq1he6vChUOVJySqM/ . 
> If a new version of RFC 5880 is prepared in the future, this question should 
> be reopened as part of that process. It would also be possible to offer a 
> standards track document to update RFC 5880 in this respect if WG consensus 
> can be found for a new approach. 
> 
> 
>> On Feb 22, 2023, at 5:36 PM, Dave Katz  wrote:
>> 
>> Cool.  And I refer once again to the paragraph in the spec about pedantic 
>> coders.  If the WG actually approves anything that reads the value of the 
>> diag field, I guess they can address all of the anomalies and hope for the 
>> best…
>> 
>> —Dave
>> 
>>> On Feb 22, 2023, at 2:30 PM, Jeffrey Haas  wrote:
>>> 
>>> [External Email. Be cautious of content]
>>> 
>>> 
>>> "Hold for update" was the expected outcome for my filing of the errata.
>>> 
>>> At best, we're telling new implementors that there's an issue here of note 
>>> in the protocol.  The mail discussion will note that there are multiple 
>>> existing implementations that have historically set the value to 0 when 
>>> transitioning to Up.
>>> 
>>> It'll also log some of what your thinking was at the time.  Since RFC 5880 
>>> already talks about cases where the value is of interest (concatenated 
>>> path, etc.) implementors already know to pay attention to the value even 
>>> when state transitions aren't happening.
>>> 
>>> Part of my own motivation to have the behavior clear has been other 
>>> proposals we've seen come and go trying to use Diag as a much more rigorous 
>>> mechanism to trigger behaviors.  I had thought I could find a draft I saw 
>>> during the mpls session at IETF 115 along these lines, but I appear to be 
>>> mistaken.  In any case, people keep wanting to use Diag for Clever Things 
>>> and it'll bite them in unpleasant places if they do so.
>>> 
>>> Greg may have recollection of the proposal I'm thinking about.
>>> 
>>> -- Jeff
>>> 
>>> 
>>> 
>>> 
>>>> On Feb 22, 2023, at 2:34 PM, Dave Katz  wrote:
>>>> 
>>>> Thanks for the background.
>>>> 
>>>> I guess the fact of the matter is that, since the issue cannot affect 
>>>> interoperability, it’s hard to imagine getting the WG to go through a 
>>>> bunch of machinations to go out of its way to fix something that is 
>>>> entirely pedantic.  In that case I think holdin

Re: [Technical Errata Reported] RFC5880 (7240)

[Jeffrey Haas]

"Hold for update" was the expected outcome for my filing of the errata.

At best, we're telling new implementors that there's an issue here of note in 
the protocol.  The mail discussion will note that there are multiple existing 
implementations that have historically set the value to 0 when transitioning to 
Up.

It'll also log some of what your thinking was at the time.  Since RFC 5880 
already talks about cases where the value is of interest (concatenated path, 
etc.) implementors already know to pay attention to the value even when state 
transitions aren't happening.

Part of my own motivation to have the behavior clear has been other proposals 
we've seen come and go trying to use Diag as a much more rigorous mechanism to 
trigger behaviors.  I had thought I could find a draft I saw during the mpls 
session at IETF 115 along these lines, but I appear to be mistaken.  In any 
case, people keep wanting to use Diag for Clever Things and it'll bite them in 
unpleasant places if they do so.

Greg may have recollection of the proposal I'm thinking about.

-- Jeff




> On Feb 22, 2023, at 2:34 PM, Dave Katz  wrote:
> 
> Thanks for the background.
> 
> I guess the fact of the matter is that, since the issue cannot affect 
> interoperability, it’s hard to imagine getting the WG to go through a bunch 
> of machinations to go out of its way to fix something that is entirely 
> pedantic.  In that case I think holding the erratum for update is the right 
> choice.  The erratum can describe the ambiguity and the WG can decide what to 
> do about it if they find another reason to update the spec...
> 
> —Dave
> 
> 
>> On Feb 22, 2023, at 11:29 AM, John Scudder  wrote:
>> 
>> Hi All,
>> 
>> Regarding Jeff’s "Given the maturity of the feature, I'd suggest sticking to 
>> the reality on the ground”, I want to step in and remind folks about what 
>> our guidelines are for processing errata [1]. They are fairly narrow, by 
>> design. One of the high-order bits of the guidelines is, "Errata are meant 
>> to fix "bugs" in the specification and should not be used to change what the 
>> community meant when it approved the RFC.”  What I take this to mean in the 
>> current context is, if the behavior specified in the RFC has been found to 
>> be ‘wrong’ (for whatever definition of ‘wrong’ you choose to apply), an 
>> erratum is definitively not the way to correct that. An erratum is to 
>> clarify or correct whatever the intent of the RFC was at time of 
>> publication. Of course, many RFCs (this one included, it seems) didn’t 
>> receive detailed scrutiny of every crevice of the spec before being declared 
>> ready for publication, and so it’s not always possible to really say that 
>> the consensus was firmly one way or the other. In such cases, I think we 
>> have to err on the side of what the words in the spec say.
>> 
>> About the furthest I’d go in documenting that (part of) the WG now thinks 
>> the specified behavior is undesirable, is to note it in a ‘hold for document 
>> update’ erratum. That seems reasonable in this case — it can lay out the 
>> pros and cons and at least creates an artifact for future implementors to 
>> notice.
>> 
>> The bottom line is that changes to specified behavior require WG and IETF 
>> consensus, and that means they require an RFC to update or obsolete the old 
>> behavior. This is one of the pointy bits of our process, that RFCs document 
>> the consensus at a moment in time, not the evolving consensus.
>> 
>> Thanks,
>> 
>> —John
>> 
>> [1] 
>> https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/
>> 
>>> On Feb 22, 2023, at 11:14 AM, Jeffrey Haas  wrote:
>>> 
>>> 
>>> Dave,
>>> 
>>> Just as a reminder, the context for why this errata is being discussed is 
>>> this inquiry:
>>> https://mailarchive.ietf.org/arch/msg/rtg-bfd/YIeCo-nQicI_OIcVncYaJM5Zz6c/
>>> 
>>> More below:
>>> 
>>> 
>>>> On Feb 17, 2023, at 12:04 PM, Dave Katz 
>>>>  wrote:
>>>>> On Feb 17, 2023, at 8:47 AM, Reshad Rahman  wrote:
>>>>> Having the diag field as breadcrumb has been extremely useful indeed. But 
>>>>> both ends can store last diag field sent/received, we don't have to keep 
>>>>> sending the diag field after the failure has cleared. It seems odd to be 
>>>>> sending a diag field which happened e.g. a year ago.
>>>> 
>>>> That property helped me when debugging my implementation, as it survives 
>>>> the restart/reboot of the far end.
>

Re: [Technical Errata Reported] RFC5880 (7240)

[Jeffrey Haas]

Dave,

Just as a reminder, the context for why this errata is being discussed is this 
inquiry:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/YIeCo-nQicI_OIcVncYaJM5Zz6c/

More below:


> On Feb 17, 2023, at 12:04 PM, Dave Katz  
> wrote:
>> On Feb 17, 2023, at 8:47 AM, Reshad Rahman > > wrote:
>> Having the diag field as breadcrumb has been extremely useful indeed. But 
>> both ends can store last diag field sent/received, we don't have to keep 
>> sending the diag field after the failure has cleared. It seems odd to be 
>> sending a diag field which happened e.g. a year ago.
> 
> That property helped me when debugging my implementation, as it survives the 
> restart/reboot of the far end.
> 
> There is also no timeout that would make sense;  “forever, for small values 
> of ‘forever'” is semantically consistent and the only thing that makes sense 
> (to me, at least).
> 
> Resetting it to zero only deletes information (albeit a tiny amount of it) 
> and doesn’t help anything;  you know that the session is up, so the 
> diagnostic for its most recent transition to non-upness is disambiguated.
> 
> Debugging broken things is a scramble for bits of data;  leaving a breadcrumb 
> is a polite gift.

From my perspective, the breadcrumb is useful to note during the transitions, 
and not simply the transitions for the state.  Examples have been given where 
the diag is updated as part of a state transition (governed by normative text 
in 5880), or transitions that may happen while the session remains up (e.g. 
concatenated path down, echo, etc.).  The RFC isn't great about saying how you 
clear such things when the state is still Up; intuitively it's to return to "No 
Diagnostic".

However, your own leaning, Dave, is "leave it set forever".  Using the above 
examples for diag signaling an event while leaving the state up, I don't think 
you mean that.

So, again, the interesting breadcrumbs are when Things Change.  Each of these 
items is an edge transition of note. If I care about the event, I care about it 
when it happens and will remember it.  I'm not going to look at diag to reflect 
this forever.

> 
>> 
>> Also the text in 6.8.1 says "The diagnostic code specifying the reason for 
>> the most recent change in the local session state.". To me that means 
>> resetting bfd.LocalDiag to 0 when the state changes to Up.
> 
> Thus the language that needs fixing (I know, I wrote it...)
> 
>> 
>> AFAIK IOS-XR and JunOS reset LocalDiag. It'd be good to hear from other 
>> implementations.
> 
> Probably.  I might have even coded it that way 20 years ago, or someone else 
> did later, thus underscoring the largely-irrelevant nature of this 
> discussion...

I did confirm with Juniper's BFD developers that it's reset to 0 when we 
transition to Up.  

Given the maturity of the feature, I'd suggest sticking to the reality on the 
ground.

-- Jeff

Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

[Jeffrey Haas]

Rob,

On Tue, Dec 20, 2022 at 11:58:03AM +, Rob Wilton (rwilton) wrote:
> (1) If the user configures:
>  
> bfd/ip-sh/unsolicited/min-interval = 1000
> 
> And no entries exist bfd/ip-sh/unsolicited/interfaces then all sessions have 
> a min-interval of 1000.  This is fine and expected.
> 
>  
> (2) If the user changes the config from (1) to:
> 
> bfd/ip-sh/unsolicited/min-interval = 1000
> bfd/ip-sh/interfaces[foo]/unsolicited/min-interval = 500
> 
> Then the all sessions on interface foo will have a min-interval of 500.  All 
> other sessions not on that interface will have a min-interval 1000.  This is 
> fine and expected.

More particularly, sessions on foo are not unsolicited.  They will require
additional configuration or bootstrapping via protocol.

> (3) ) If the user changes the config from (1) to just:
> 
> bfd/ip-sh/unsolicited/min-interval = 1000
> bfd/ip-sh/interfaces[foo]/unsolicited/local-multiplier = 2
> 
> then with the interface 
> min-interval/desired-min-tx-interval/required-min-rx-interval defaults this 
> is semantically equivalent to the user configuring:
> 
> bfd/ip-sh/unsolicited/min-interval = 1000
> bfd/ip-sh/interfaces[foo]/unsolicited/local-multiplier = 2
> bfd/ip-sh/interfaces[foo]/unsolicited/desired-min-tx-interval = 100
> bfd/ip-sh/interfaces[foo]/unsolicited/required-min-rx-interval = 100

While I understand this is what you believe the intent is, the space isn't
quite global vs. per-interface, it's "unsolicited global" vs. per-interface.
I wouldn't expect the min-interval to be inherited in this fashion.

> So, despite the fact that the user hasn't explicitly configured min-interval, 
> desired-min-tx-interval or required-min-rx-interval under the interface, just 
> by configuring something else under the interface causes these defaults to 
> come into scope and causes the rx/tx intervals to operationally change on 
> interface foo.
> 
> This is what I would regard as surprising.  The interface behaviour has 
> changed as a side effect of some somewhat unrelated configuration.
> 
> Normally, with hierarchical configuration, I would expect less-specific 
> settings to take effect unless explicitly overridden by a more specific 
> setting.
> 
> If instead of the default statements under the interface config, the 
> description stated that if not configured, the default inherits from 
> bfd/ip-sh/unsolicited/min-interval, then if the user entered the 
> configuration in (3), then the min-interval on interfaces[foo] wouldn't have 
> changed at all.  It would keep using the (explicitly configured, or implicit 
> default) value from bfd/ip-sh/unsolicited/min-interval.

Again, your example is understood, but I don't think it matches the intent.
We'll see how the authors respond.

I'd rather not see the unsolicited global behavior completely removed. (It
already requires a feature.)  But perhaps that's the best option.

> As example of this hierarchical configuration, in the style that I describe, 
> is in RFC 8342, C.2.  Added by Phil Shafer, if I recall correctly ...

Little surprise, I understand Phil's example quite well.  In that example,
the hierarchy ends up being largely consistent across the configuration
scopes, and the inheritance model needs to be called out in the
documentation.

In this BFD unsolicited case, the per-interface state has a leaf for
unsolicited while the "global" case is a unsolicited container that has
configuration parameters.  So, the point of similarity is a bit split.

FWIW, in the model Phil is citing, even then inheritance isn't completely
transparent.  As an example, address-family configuration when done in any
more specific scope requires a full re-specification of the families.  This
is because if configuration at the more specific scope caused a union over
the previously configured families, the syntax would then require a
"no-address-family" negative configuration to undo the inheritance.

Inheritance is a mess. :-)

-- Jeff

Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

[Jeffrey Haas]

Rob,

On Mon, Dec 19, 2022 at 11:37:12AM +, Rob Wilton (rwilton) wrote:
> You are correct that in the case that the client has not configured an entry 
> in  "... bfd:bfd/ip-sh/interfaces" then this list element does not exist, and 
> hence it seems that the global value would take effect.
> 
> But if the client configured anything under that subtree tree (e.g., if they 
> choose to configure "... 
> bfd:bfd/ip-sh/interfaces[eth0]/authentication/key-chain" then those other 
> defaults values would suddenly come in effect (even if not explicitly 
> configured by the client) and logically override the global values for those 
> interfaces.  Is this the intent?   I would think that it might be somewhat 
> surprising.  Normally, for hierarchical configuration, I would only expect 
> the per-interface settings to override a global setting if the per-interface 
> setting has been explicitly configured.

In trying to filter this through the Principle of Least Astonishment, I'm of
mixed opinions which side a default on interface configuration that
overrides global configuration would be.  I've seen it both ways in various
configuration paradigms.

I'm insufficiently versed in such inheritance examples in other IETF models.
If the YANG doctors have any thoughts here, they'd be highly pertinent.

In the absence of a conflicting paradigm, the behavior covered by the
default false on more specific configuration is that it fails in a safe
fashion.  If global configuration is present, and is in this very permissive
mode, any per-interface override is probably being made for particular
reasons.  If you override global in some places, doing so in others somewhat
makes sense.

That said, let's see what the authors' collective intents are.

> I think that SHOULD is clearer than MAY, or another way of stating this could 
> be:
> 
> ".., the passive side SHOULD* create a matching BFD session toward the active 
> side, unless not permitted by local configuration or policy."

While more succinct, the implication is fail-open without policy.  (Shades
of the subtleties that got us RFC 8212.)

Perhaps instead:
"..., when permitted by local configuration or policy, the passive side
SHOULD create a matching BFD session toward the active side" ?


-- Jeff

Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

[Jeffrey Haas]

[Speaking as chair and shepherd, not an author]

Rob,

On Mon, Dec 12, 2022 at 09:03:18AM -0800, Robert Wilton via Datatracker wrote:
> DISCUSS:
[...]
> Please see my comments below for more details, but I'm balloting discuss on 3
> points: (1) The document is somewhat unclear as to whether the configuration 
> is
> applied hierarchically (I presume that it is, if not then my second discuss
> point is not valid and can be ignored). (2) As specified, I don't think that
> the hierarchical configuration will work, because the interface level leaf
> "defaults" will override an explicit value configured globally.  I.e.,
> logically, the interface level leaf, if in scope, will always have a value.

Reshad has been more engaged in such YANG details of late so this may be
better addressed by him when he gets cycles again.

Yes, the intent is for there to be hierarchy.  I understand your concern
about the default, and perhaps I have a misunderstanding how defaults
manifest in YANG modules.

My impression had been that defaults are only relevant when the containing
element was manifested in the model.  So, if it was the case that:
- The global instance for BFD's ip-sh unsolicted container was created
- But that a specific instance of BFD's ip-sh per interface container was
  NOT created...
- There is no effective configuration state for the per-interface
  unsolicited container.  I.e. this is not a presence node.

I'm rusty in my YANG, so if this impression is incorrect a pointer to the
relevant point in the current YANG 1.1. RFC would be helpful.

> COMMENT:
> --
> 
> Moderate level comments:
> 
> (1) p 3, sec 2.  Procedures for Unsolicited BFD
> 
>When the passive side receives a BFD Control packet from the active
>side with 0 as "Your Discriminator" and does not find an existing BFD
>session, the passive side MAY create a matching BFD session toward
>the active side, if permitted by local configuration and policy.
> 
> I'm surprised that this is only a MAY and not a SHOULD or MUST.  I.e., if the
> local configuration & policy allows passive BFD sessions why would they not be
> created?

Basically, "because it wants to do it that way".  A SHALL implies that the
local system shouldn't get a choice about this.  Framed a different way, it
means the discussion on "policy" becomes a lot uglier about needing to
expose numerous implementation-specific internal details about why it would
or would not want to bring up a session. 

An example might be a limit on maximum number of sessions.

MAY provides the appropriate hint that this the desired behavior.  SHOULD
could be one steps stronger to imply "well, we're really discussing this in
the spec" and I don't think the text would be harmed by moving to that.

It absolutely couldn't be MUST.

> (6) p 3, sec 2.  Procedures for Unsolicited BFD
> 
>Passive unsolicited BFD support MUST be disabled by default, and MUST
>require explicit configuration to be enabled.  On the passive side,
>the desired BFD parameters SHOULD be configurable.  The passive side
>MAY also choose to use the parameters that the active side uses in
>its BFD Control packets.  The "My Discriminator", however, MUST be
>chosen to allow multiple unsolicited BFD sessions.
> 
> Rather then configured values on the passive side, did the authors consider
> setting minimum configuration limits?  E.g., rather than define desired
> send/receive limits, instead, configure lower bounds on what the minimum tx
> interval may be (to prevent DDOS attacks).

Any such values will be locally significant to the implementation.  

My analogy from within SNMP land, putting in such a recommendation in a
compliance statement simply means implementations get forced to try to ship
something that says "this was wrong, we're doing this other thing instead".


-- Jeff

Re: Zaheduzzaman Sarker's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

[Jeffrey Haas]

Zahed,

[Speaking as chair/shedpherd, not an author.]

On Wed, Dec 14, 2022 at 11:32:46AM -0800, Zaheduzzaman Sarker via Datatracker 
wrote:
> DISCUSS:
> --
> 
> Thanks for working on this specification.
> 
> Thanks to Magnus Westerlund for the TSVART review, based on that review and my
> own read, I am supporting both Lars's and Roman's discuss.
> 
> On top of that, as this document claims - "with "unsolicited BFD" there is
> potential risk for excessive resource usage by BFD from "unexpected" remote
> systems". This translates to me as potential injection of huge amount of
> traffic which is lacking a self-regulation mechanism in this specification. To

I suspect it's an unfamiliarity with core RFC 5880 behaviors that's lead you
to that incorrect observation.  BFD sessions negotiate the least aggressive
timer in each direction based on the timers present in each BFD PDU.

See RFC 5880 §6.8.7 for details.

It's also not uncommon for implementations to dyanmically adjust their
timers based on load within some constraints.  When that's not possible,
BFD traffic that becomes unsustainable causes the BFD sessions to start
losing packets, which in many cases will cause the session to transition to
the Down state - and thus back to slow PDU transmission.

The caveat in this draft is related to an unexpected number of BFD sessions.
Operators, who are already generally aware of BFD session and timer scaling
for their systems, need to plan within the bounds of their deployment.  For
example, if a /24 interface is permitted, it's not unreasonable for 255
sessions to be possible.  If scaling requires fewer to be guaranteed... then
configure that in the ACL.

"If it hurts, don't do that."

> large degrees the traffic volume could have random effects on the routing 
> plane
> and what links are considered up etc. We can hide all these by saying "Deploy
> the feature only in certain "trustworthy" environment"", then I am completely
> missing the definition of "trustworthy" environment". I would like to discuss
> that.

The environment must be under reasonable operational control to satisfy the
scaling of the impacted system.  What words would you prefer to have there
instead?  How would those words change if you want to permit this feature to
be utilized when the operational environment spans multiple entities, such
as at an exchange point (IXP)?


"If it hurts, don't do that."

And note: You can happily end up with a badly behaved environment through
configuration as well.

> --
> COMMENT:
> --
> 
> Additional comments -
> 
> * This document also says - "When an Unsolicited BFD session goes down, an
> implementation MAY retain the session state for a period of time. Retaining
> this state can be useful for operational purposes." I am missing any 
> discussion
> on the reduced functionality or any indication if the selected period time has
> any advantages or disadvantages. To be honest, without proper discussion or
> indication of some default values, I would remove the entire sentence or if
> this is just an additional implementation advice, I would drop the normative
> MAY.

The desired behavior here is that operational state associated with a
session and visible in management infrastructure (such as YANG modules)
requires that the state not disappear immediately when the session goes
down.  Such a behavior is indistinguishable from a very fast delete of
configuration state.

The reason the MAY was originally chosen was to counter possible arguments
that the state MUST be deleted immediately.

My recommendation would be to retain the MAY, but moving to the non RFC 2119
"may" would still satisfy the desired behavior. This is to inform
implementors that immediate deletion is not the obvious implementation
requirement.

-- Jeff

Re: Lars Eggert's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

[Jeffrey Haas]

Lars,

[Speaking in role as chair/shepherd and not author.]

On Mon, Dec 12, 2022 at 06:27:25AM -0800, Lars Eggert via Datatracker wrote:
> ## Discuss
> 
> ### Section 7.1, paragraph 3
> ```
>  The same security considerations and protection measures as those
>  described in [RFC5880] and [RFC5881] apply to this document.  In
>  addition, with "unsolicited BFD" there is potential risk for
>  excessive resource usage by BFD from "unexpected" remote systems.  To
>  mitigate such risks, the following measures are mandatory:
> 
>  *  Limit the feature to specific interfaces, and to single-hop BFD
> with "TTL=255" [RFC5082].
>  *  Apply "policy" to allow BFD packets only from certain subnets or
> hosts.
>  *  Deploy the feature only in certain "trustworthy" environment,
> e.g., at an IXP, or between a provider and its customers.
>  *  Use BFD authentication, see [RFC5880].  In some environments, e.g.
> when using an IXP, BFD authentication can not be used because of
> the lack of coordination into the operation of the two endpoints
> of the BFD session.  In other environments, e.g. when BFD is used
> to track the next hop of static routes, it is possible to use BFD
> authentication: this comes with the extra cost of configuring
> matching key-chains at the two endpoints.  If BFD authentication
> is used, the Meticulous Keyed SHA1 mechanism SHOULD be used.
> ```
> BFD can be configured to send large volumes of traffic, and it sends
> it without congestion control. When a past IESG approved BFD for
> standardization in that form, it was exactly because both endpoints
> needed to be configured, which significantly reduces the
> possibility/impact of unilateral misconfiguration. I don't believe
> the suggestions above provide nearly the same level of protection.
> Also, if (all of?) these are mandatory, that needs to be made very
> clear, i.e., using RFC2119 terms here and elsewhere in the document
> (where it currently says these mechanisms are recommended...)

Strictly from an English standpoint, I'm unclear what the appropriate
response is to your request above.  The "mandatory" word leading the bullet
points certainly could be treated as each of those points as having a
leading "MUST" there.  Or alternatively, the word mandatory itself could be
replaced with MUST.  

Would you be satisfied by replacing the sentence prior to the bullet points
with:

"To mitigate such risks, implementations of unsolicited BFD MUST:"

?

With regard to the concerns about "large volumes of traffic":
- Those mandatory items restrict possible unsolicted sessions to a directly
  connected interface, on subnets that are part of an ACL, and ideally with
  BFD authentication mechanisms.
- BFD doesn't go into its fast mode until the BFD state machinery goes into
  the Up state. Thus, the passive side will not send traffic at speed until
  all of the requirements above are satisfied AND the state machine permits
  the session to advance to Up.
- An active implementation that doesn't respect the state machinery isn't
  compliant.  Arguably, it's simply a DoS attacker that just happens to be
  using BFD ports as its target.

-- Jeff

Segment routing profiles for BFD

[Jeffrey Haas]

As commented at the mic during the IETF 115 spring session, there are
currently 5 documents covering BFD profiles for various segment routing
technologies.  One is adopted, the other four have yet to be adopted.

I have assembled a list of the documents as part of the regular BFD wiki
maintenance:
https://wiki.ietf.org/en/group/bfd/non-wg-related-activities

My request to the spring working group is perhaps fewer documents adopted by
spring covering these various profiles.  Since there is overlap in many of
the procedures, the document effectively could become "here is the desired
testing mechanism" with the related example encapsulation.

I'd like to thank the various authors for taking on the work of doing these
small documents.  It's necessary, and mostly thankless work.  However,
please let's find a way to reduce review work across both spring and bfd.

Thanks!

-- Jeff

Re: Regarding resetting bfd.LocalDiag back to No Diagnostic (RFC 5880)

[Jeffrey Haas]

FWIW, my own reading through the text comes to similar conclusion.  The
transition for the state machine would be an appropriate place to reset the
LocalDiag back to No Diagnostic.

Glancing at part of Juniper's implementation, it seems we'll reset the Diag
when the session returns to Up. 

It might be good if the RFC was clearer about when this happens.  I have
filed an errata on the issue.

-- Jeff


On Fri, Sep 30, 2022 at 06:55:12PM +, Reshad Rahman wrote:
>  Hi Glebs,
> I don't know for sure what the authors intended, but in the implementations I 
> was involved with (albeit many years ago), the Diag field got reset to "No 
> Diagnostic" when a session goes back up.
> Also, "The diagnostic code specifying the reason for the most recent change 
> in the local session state" implies that the diag should be reset to No Diag 
> when the session goes up (last state change)?
> I need to check RFC5880 but it'd be good to hear from various vendors on 
> this.  Regards,Reshad (no hat).
> On Friday, September 23, 2022, 10:07:36 AM EDT, Gļebs Ivanovskis 
>  wrote:  
>  
>
> Hi,
>  
> I have a question regarding bfd.LocalDiag State Variable. In section 6.8.1. 
> State Variables it says:
> bfd.LocalDiag
> 
>   The diagnostic code specifying the reason for the most recent
>   change in the local session state.  This MUST be initialized to
>   zero (No Diagnostic).
>  
> Then in many places throughout the text it is said that bfd.LocalDiag needs 
> to be set to other values in response to different failures. But nowhere it 
> is said that bfd.LocalDiag needs to be reset to "No Diagnostic". Only the 
> text I quoted above mentions bfd.LocalDiag together with "No Diagnostic", but 
> it talks only about BFD session initialization.
>  
> So, if implementation rigorously follows the letter of RFC, then it leads to 
> a peculiar situation when a session goes back Up after, say, "Control 
> Detection Time Expired", but the Diag field of the packet keep holding the 
> diagnostic from the time session was Down. Or am I missing something?
>  
> Best regards,
>  Glebs
>  
>  
> 
>

Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[Jeffrey Haas]

Xiao Min,

On Sat, Nov 05, 2022 at 01:00:27PM +0800, xiao.m...@zte.com.cn wrote:
> To restate my question, on a given device receiving, for a given VNI, will 
> there ever be multiple sets of the same IP addresses?
> 
> If yes, the addition of the MAC addresses for initial multiplexing makes 
> sense.  Otherwise, perhaps they are unneeded?
> [XM-2]>>> The answer to your first question is Yes. In section 4.1 of this 
> document it says In BFD over Geneve, a BFD session is originated and 
> terminated at
>  VAP, usually one NVE owns multiple VAPs, so multiple BFD sessions may
>  be running between two NVEs, there needs to be a mechanism for
>  demultiplexing received BFD packets to the proper session.
>  Furthermore, due to the fact that [RFC8014] allows for N-to-1 mapping
>  between VAP and VNI at one NVE, multiple BFD sessions between two
>  NVEs for the same VNI are allowed.

The BFD for VXLAN procedures would similarly need to apply this type of
demultiplexing.  However, that document didn't list those details.
Perhaps listing them in the geneve document is clearer.

That said, if this is the case, shouldn't there also be discussion about the
Inner VLAN tag portion of the Inner Ethernet Header?

> What I'm far more puzzled by is the source port demultiplexing step.  
> Thisisn't normal for RFC 5881.  Why is there a desire to add this to initial 
> demultiplexing?
> [XM]>>> In section 4 of RFC 5881 it says 
> 
[...]

> If you don't need to explicitly control more than one session between the 
> same VNI, for the same IP address pairs, on the same device, you can simply 
> demultiplex based on the UDP destination port for BFD single hop as per RFC 
> 5881 procedures.
> 
> If you have need for such explicit control, such additional procedure is fine.
> 
> 
> [XM-2]>>> Yes, I believe there is such a need. Furthermore, the provision for 
> source UDP port is optional even if it's included in the demultiplexing 
> fields, because the source UDP port is not the only field for demultiplexing. 
> In other words, if an implementation selects not to configure the source UDP 
> port, but just use the default one, this implementation can still comply with 
> this specification.

There normally isn't a default source port - its value is simply expected to
be in the ephemeral port range.

By listing it in the configuration and demultiplexing procedures, it becomes
additional configuration that must be consistent between each side of a BFD
session.

---

If the NVO3 Working Group is comfortable with all of the requirements for
session configuration, the procedures are fine for BFD.  I believe this
brings me to my final comment, which may be raised by the Area Directors as
well as part of their review: There is no YANG module for this feature.

I don't believe the IESG is requiring YANG modules at this time.  BFD for
VXLAN itself doesn't have a YANG module.  However, the creation of such a
module would highlight what the configuration parameters are for this
document.

Perhaps the NVO3 group should consider such a YANG module for the future.

-- Jeff

Re: A missing read/write attribute in RFC 9314?

[Jeffrey Haas]

Thank you for the correction and apologies for my error in copying, Xiao Min.

It would seem that Juniper is unique in using the learned MAC address for the 
session. :-)

However, none of the implementations permit dynamic use of both. We have 
compliant implementations that do not need additional YANG configuration.

-- Jeff


> On Nov 3, 2022, at 9:09 PM,   
> wrote:
> 
> Jeff,
> 
> 
> 
> To clarify ZTE's implementation, please see inline...
> 
> Original
> From: JeffreyHaas mailto:jh...@pfrc.org>>
> To: Reshad Rahman mailto:res...@yahoo.com>>;
> Cc: BFD WG mailto:rtg-bfd@ietf.org>>;Alexander Vainshtein 
> mailto:alexander.vainsht...@rbbn.com>>;Nitsan 
> Dolev mailto:nitsan.do...@rbbn.com>>;Shell Nakash 
> mailto:shell.nak...@rbbn.com>>;James Lian 
> mailto:james.l...@rbbn.com>>;
> Date: 2022年11月04日 07:17
> Subject: Re: A missing read/write attribute in RFC 9314?
> [In an attempt to close this thread, replying to my older message...]
> 
> On Wed, Oct 19, 2022 at 03:24:57PM -0400, Jeffrey Haas wrote:
> > On Mon, Oct 17, 2022 at 06:01:05PM +, Reshad Rahman wrote:
> > >  Hi Sasha,
> > > Apologies for the delay.
> > > Yes this config knob is not present in RFC9314. I don't think it's 
> > > something we did not add on purpose, afair it's something we missed. 
> >  
> > I'm going to offer a contrary view.  Given that it may save us some work,
> > that might be appreciated. :-)
> >  
> > Repeating the relevant bit of text:
> >  
> > >   All implementations MUST be able to send and receive BFD packets in
> > >   Up state using the dedicated MAC address.  Implementations supporting
> > >   both, sending BFD Up packets with the dedicated and the received MAC,
> > >   need to offer means to control the behavior.
> >  
> > We have a mandatory mode, and an OPTIONAL mode.  The BFD YANG module is
> > supporting, effectively, the mandatory.
> >  
> > Modeling-wise, what we'd be looking for is adding this knob protected under
> > the appropriate new if-feature for it.
> >  
> > I think what this work looks like is:
> > 1. Survey of implementations to see whether they do this behavior, and what
> > their knob is, if so.
> > 2a. If no implementations have such a knob, it's quite reasonable to just 
> > let
> > the vendor do their own augmentation module for it.
> > 2b. If multiple vendors implement it, we need an update.
> > 3. If we need an update, one path is to -bis RFC 9314, the other is to
> > simply do a trivial augmentation RFC.  (Mahesh notes this point in his
> > reply.)
> 
> What we have seen in a partial vendor implementation survey:
> - Arrcus only uses the dedicated multicast MAC for the Up session 
> (mjethanandani)
> - Huawei only uses the dedicated multicast MAC for the Up session (mach.chen)
> - Juniper will use the discovered unicast MAC for the Up session. (jhaas)
> - ZTE will use the discovered unicast MAC for the Up session. (xiao.min)
> 
> [XM]>>> That's NOT what I replied to the survey [1]. The correct one is as 
> below.
> 
> - ZTE only uses the dedicated multicast MAC for the Up session. (xiao.min)
> 
> [1]  
> <https://mailarchive.ietf.org/arch/msg/rtg-bfd/_Ie2xUP5UskH3M2yE4V-JVO8g_g/>https://mailarchive.ietf.org/arch/msg/rtg-bfd/_Ie2xUP5UskH3M2yE4V-JVO8g_g/
>  <https://mailarchive.ietf.org/arch/msg/rtg-bfd/_Ie2xUP5UskH3M2yE4V-JVO8g_g/>
> 
> Best Regards,
> 
> Xiao Min
> 
> 
> None of these implementations support a knob to choose the behavior.  They
> pick a mode and stick with it.
> 
> My conclusion is that we likely do not need an IETF update to the BFD YANG
> module here.  If an implementation comes into being that makes this
> selectable, YANG permits vendor augmentation to address the additional
> configuration state.
> 
> If it becomes the case that multiple vendors implement such a knob, IETF
> should consider the trivial augmentation module to standardize the knob to
> provide for ease of interop.
> 
> To say that I'm relieved that we don't need a further update to BFD YANG at
> this time is an understatement. :-)
> 
> -- Jeff

Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[Jeffrey Haas]

Xiao Min,


> On Nov 3, 2022, at 10:52 PM,   
> wrote:
>> : If the BFD packet is received with Your Discriminator equals to 0, the BFD
>> : session MUST be identified using the VNI number, and the inner
>> : Ethernet/IP/UDP Header, i.e., the source MAC, the source IP, the 
>> destination
>> : MAC, the destination IP, and the source UDP port number present in the 
>> inner
>> : Ethernet/IP/UDP header.
>> 
>> Not being familiar with Geneve configuration at all, I'll presume that with
>> there is a motivation for using the MAC addresses within a given VNI context
>> in addition to the IP addresses.  If this is clear from typical Geneve
>> procedures, it might be worth a nod to the appropriate section.  I'll note
>> that this point of procedure doesn't seem to have a parallel in BFD for 
>> vxlan.
> [XM]>>> Would you please elaborate a bit on the possible nod? As I understand 
> it, the reason why there is no a parallel in RFC 8971 is that only one BFD 
> session using the management VNI is needed between a pair of VTEPs, so there 
> is no demultiplexing procedure needed in RFC 8971.
> 
> 

To restate my question, on a given device receiving, for a given VNI, will 
there ever be multiple sets of the same IP addresses?

If yes, the addition of the MAC addresses for initial multiplexing makes sense. 
 Otherwise, perhaps they are unneeded?


> 
> What I'm far more puzzled by is the source port demultiplexing step.  This
> isn't normal for RFC 5881.  Why is there a desire to add this to initial 
> demultiplexing?
> [XM]>>> In section 4 of RFC 5881 it says 
> 
> An implementation MAY use
>the UDP port source number to aid in demultiplexing incoming BFD
>Control packets, but ultimately the mechanisms in [BFD 
> ] MUST be used
>to demultiplex incoming packets to the proper session.
> It seems adding the UDP source port is helpful, what do you think?
> 
> 

It actually can make configuration more difficult.  You must then have 
provisioning for the UDP ports for your sessions on each side of things.  

If you don't need to explicitly control more than one session between the same 
VNI, for the same IP address pairs, on the same device, you can simply 
demultiplex based on the UDP destination port for BFD single hop as per RFC 
5881 procedures.

If you have need for such explicit control, such additional procedure is fine.

-- Jeff

Re: Extending WG LC for draft-ietf-nvo3-bfd-geneve by two weeks

[Jeffrey Haas]

Matthew,

On Fri, Oct 21, 2022 at 09:37:13AM +, Bocci, Matthew (Nokia - GB) wrote:
> NVO3 and BFD working groups,
> 
> To give more time to review and comment on this draft in the light of the 
> draft submission deadline of 24th October, I am extending this WG last call 
> to Friday 4th November 2022.
> 
> Please review and post any comments to the NVO3 list (including whether you 
> support publication as an RFC).

Thanks for your patience.  I have reviewed the BFD for geneve draft.  My
comments are below.

Section 4:
: Destination IP: IP address of a VAP of the terminating NVE. If the VAP of
: the terminating NVE has no IP address, then the IP address 127.0.0.1 for
: IPv4 or ::1/128 for IPv6 MUST be used.

The procedure here is clear.  I suspect that those who have been exposed to
other prior tunnel endpoint destination IP address discussions may note that
more of the "loopback range" has been used.  In particular, the comparable
BFD for vxlan - RFC 8971, Section 3.

While I'm not suggesting that the draft change its behavior, the Working
Group may wish to be aware that this may come up as a point of discussion.

That said, the IESG has collective amnesia about this point when it shows up
in other proposals so I think you're fine. :-)

: In BFD over Geneve, a BFD session is originated and terminated at VAP,
: usually one NVE owns multiple VAPs, so multiple BFD sessions may be running
: between two NVEs, there needs to be a mechanism for demultiplexing received
: BFD packets to the proper session

The above is a bit of a run-on sentence.  Suggest minor punctuation changes:

"In BFD over Geneve, a BFD session is originated and terminated at VAP,
usually one NVE owns multiple VAPs. Since multiple BFD sessions may be running
between two NVEs, there needs to be a mechanism for demultiplexing received
BFD packets to the proper session."

: If the BFD packet is received with Your Discriminator equals to 0, the BFD
: session MUST be identified using the VNI number, and the inner
: Ethernet/IP/UDP Header, i.e., the source MAC, the source IP, the destination
: MAC, the destination IP, and the source UDP port number present in the inner
: Ethernet/IP/UDP header.

Not being familiar with Geneve configuration at all, I'll presume that with
there is a motivation for using the MAC addresses within a given VNI context
in addition to the IP addresses.  If this is clear from typical Geneve
procedures, it might be worth a nod to the appropriate section.  I'll note
that this point of procedure doesn't seem to have a parallel in BFD for
vxlan.

What I'm far more puzzled by is the source port demultiplexing step.  This
isn't normal for RFC 5881.  Why is there a desire to add this to initial
demultiplexing?

The same comment on UDP port number holds for section 5.1 for IP
encapsulation.

-- Jeff

Re: A missing read/write attribute in RFC 9314?

[Jeffrey Haas]

[In an attempt to close this thread, replying to my older message...]

On Wed, Oct 19, 2022 at 03:24:57PM -0400, Jeffrey Haas wrote:
> On Mon, Oct 17, 2022 at 06:01:05PM +, Reshad Rahman wrote:
> >  Hi Sasha,
> > Apologies for the delay.
> > Yes this config knob is not present in RFC9314. I don't think it's 
> > something we did not add on purpose, afair it's something we missed. 
> 
> I'm going to offer a contrary view.  Given that it may save us some work,
> that might be appreciated. :-)
> 
> Repeating the relevant bit of text:
> 
> >   All implementations MUST be able to send and receive BFD packets in
> >   Up state using the dedicated MAC address.  Implementations supporting
> >   both, sending BFD Up packets with the dedicated and the received MAC,
> >   need to offer means to control the behavior.
> 
> We have a mandatory mode, and an OPTIONAL mode.  The BFD YANG module is
> supporting, effectively, the mandatory.
> 
> Modeling-wise, what we'd be looking for is adding this knob protected under
> the appropriate new if-feature for it.
> 
> I think what this work looks like is:
> 1. Survey of implementations to see whether they do this behavior, and what
> their knob is, if so.
> 2a. If no implementations have such a knob, it's quite reasonable to just let
> the vendor do their own augmentation module for it.
> 2b. If multiple vendors implement it, we need an update.
> 3. If we need an update, one path is to -bis RFC 9314, the other is to
> simply do a trivial augmentation RFC.  (Mahesh notes this point in his
> reply.)

What we have seen in a partial vendor implementation survey:
- Arrcus only uses the dedicated multicast MAC for the Up session 
(mjethanandani)
- Huawei only uses the dedicated multicast MAC for the Up session (mach.chen)
- Juniper will use the discovered unicast MAC for the Up session. (jhaas)
- ZTE will use the discovered unicast MAC for the Up session. (xiao.min)

None of these implementations support a knob to choose the behavior.  They
pick a mode and stick with it.

My conclusion is that we likely do not need an IETF update to the BFD YANG
module here.  If an implementation comes into being that makes this
selectable, YANG permits vendor augmentation to address the additional
configuration state.

If it becomes the case that multiple vendors implement such a knob, IETF
should consider the trivial augmentation module to standardize the knob to
provide for ease of interop.

To say that I'm relieved that we don't need a further update to BFD YANG at
this time is an understatement. :-)

-- Jeff

Re: A missing read/write attribute in RFC 9314?

[Jeffrey Haas]

> On Oct 19, 2022, at 3:24 PM, Jeffrey Haas  wrote:
> 
> I think what this work looks like is:
> 1. Survey of implementations to see whether they do this behavior, and what
> their knob is, if so.

I have confirmed that Juniper's implementation does not support the behavior 
described in this thread.  When in the Up state, Juniper's BFD on LAG uses the 
discovered unicast MAC address.

Xiao Min reports that ZTE's implementation behaves similarly.

It'd be good to get responses from Cisco, Huawei, and Nokia.

-- Jeff

Re: [EXTERNAL] A missing read/write attribute in RFC 9314?

[Jeffrey Haas]

Xiao Min,

Thank you for researching this.  That brings the count of implementations that 
don't support such behavior to at least two.

-- Jeff


> On Oct 19, 2022, at 11:23 PM,   
> wrote:
> 
> Jeff, Sasha, Reshad, et al.,
> 
> 
> 
> Please see inline...
> 
> 
> 
> Best Regards,
> 
> Xiao Min
> 
> Original
> From: JeffreyHaas 
> To: Alexander Vainshtein ;
> Cc: Reshad Rahman ;BFD WG ;Nitsan Dolev 
> ;Shell Nakash ;James Lian 
> ;
> Date: 2022年10月20日 04:17
> Subject: Re: [EXTERNAL] Re: A missing read/write attribute in RFC 9314?
> Sasha,
> 
> On Wed, Oct 19, 2022 at 08:07:06PM +, Alexander Vainshtein wrote:
> > And I have not encountered implementations by other vendors that support 
> > this option (with or without the knob in question). My guess (FWIW) is that 
> > this would make an implementation much more complicated while the benefits 
> > would be minimal.
> 
> BFD on LAG was a contentious and fussy bit of RFC work.  Much of the earlier
> headache about whether multicast or unicast MACs were to be involved had to
> do with chip details.  However, I suspect as time has passed and it's become
> a more common feature across the vendors, things may have stabilized.
> 
> > So I think that we indeed need a survey you have proposed.
> 
> I've internally enquired about this at Juniper.
> 
> A brief survey of some other implementations' manuals doesn't seem to
> suggest any knob for this behavior.  It'd be good to get more formal
> statement of compliance from these vendors.
> 
> [XM]>>> I've consulted my colleagues having implemented BFD on LAG at ZTE, 
> only the dedicated multicast MAC is used and there is no any knob (also not 
> suggested).
> 
> 
> > If there are no implementations exercising optional behavior, deprecating 
> > it in 7130 could be considered as well.
> 
> Absolutely.  That would be an appropriate errata response once we have some
> data.
> 
> [XM]>>> Yes, it seems more appropriate to take action on RFC 7130 rather than 
> 9314.
> 
> 
> -- Jeff
> 
> 

Re: A missing read/write attribute in RFC 9314?

[Jeffrey Haas]

On Mon, Oct 17, 2022 at 06:01:05PM +, Reshad Rahman wrote:
>  Hi Sasha,
> Apologies for the delay.
> Yes this config knob is not present in RFC9314. I don't think it's something 
> we did not add on purpose, afair it's something we missed. 

I'm going to offer a contrary view.  Given that it may save us some work,
that might be appreciated. :-)

Repeating the relevant bit of text:

>   All implementations MUST be able to send and receive BFD packets in
>   Up state using the dedicated MAC address.  Implementations supporting
>   both, sending BFD Up packets with the dedicated and the received MAC,
>   need to offer means to control the behavior.

We have a mandatory mode, and an OPTIONAL mode.  The BFD YANG module is
supporting, effectively, the mandatory.

Modeling-wise, what we'd be looking for is adding this knob protected under
the appropriate new if-feature for it.

I think what this work looks like is:
1. Survey of implementations to see whether they do this behavior, and what
their knob is, if so.
2a. If no implementations have such a knob, it's quite reasonable to just let
the vendor do their own augmentation module for it.
2b. If multiple vendors implement it, we need an update.
3. If we need an update, one path is to -bis RFC 9314, the other is to
simply do a trivial augmentation RFC.  (Mahesh notes this point in his
reply.)

Sasha, did you have an implementation needing this knob that triggered this
investigation?

-- Jeff

Fwd: Directorate Early Reviews

[Jeffrey Haas]

> Begin forwarded message:
> 
> From: Andrew Alston - IETF 
> Subject: Directorate Early Reviews
> Date: October 12, 2022 at 3:29:38 AM EDT
> To: "rtg-cha...@ietf.org" 
> Resent-From: 
> Resent-To: res...@yahoo.com, slitkows.i...@gmail.com, 
> daniele.ceccare...@ericsson.com, manka...@cisco.com, 
> david.sinicr...@gmail.com, yingzhen.i...@gmail.com, pengshup...@huawei.com, 
> matthew.bo...@nokia.com, gunter.van_de_ve...@nokia.com, 
> oscar.gonzalezded...@telefonica.com, andrew-i...@liquid.tech, 
> jie.d...@huawei.com, aretana.i...@gmail.com, jh...@pfrc.org, 
> zhang.zh...@zte.com.cn, a...@cisco.com, julien.meu...@orange.com, 
> j...@joelhalpern.com, cho...@chopps.org, aldrin.i...@gmail.com, 
> gjs...@gmail.com, s...@cisco.com, tonysi...@gmail.com, j...@juniper.net, 
> lber...@labn.net, liyiz...@huawei.com, mcr+i...@sandelman.ca, 
> mmcbri...@gmail.com, padma.i...@gmail.com, janos.far...@ericsson.com, 
> luismiguel.contrerasmuri...@telefonica.com, vbee...@juniper.net, 
> ronald.intv...@tno.nl, jefftant.i...@gmail.com, stewart.bry...@gmail.com, 
> g...@gigix.net, h...@netflix.com, r...@tropicalstormsoftware.com, 
> zhangfa...@huawei.com, l...@pi.nu, tsaad@gmail.com, 
> james.n.guich...@futurewei.com, d3e3e3@gmail .com, d...@dhruvdhody.com, 
> dominique.bart...@orange.com, n.leym...@telekom.de, zzh...@juniper.net, 
> wangai...@tsinghua.org.cn, agma...@gmail.com, mach.c...@huawei.com, 
> tal.mizrahi@gmail.com, mariainesrob...@googlemail.com, dfe...@labn.net, 
> eve.m.schoo...@intel.com, et...@ieee.org, ke...@arrcus.com, r...@riw.us, 
> bruno.decra...@orange.com, s...@ndzh.com, haoyu.s...@futurewei.com, 
> vic...@jvknet.com
> 
> Hi All,
>  
> Following the helpful feedback received during chair’s meeting and further 
> discussion between the routing AD’s, we would like to propose the following:
>  
> We will require early directorate reviews before documents come to the AD’s 
> to enter the publication queue
> We suggest that these reviews are done either in parallel with the working 
> group last call or between the working group last call and publication request
> In the case of the early directorate review being done in parallel with the 
> last call, it is suggested to use this approach only if there is indication 
> that the document is stable, since we ask that the early review is done on 
> the version of the document that will be received by the AD’s at the time of 
> requested publication.
> While we require early review from the routing directorate, it is in the 
> chair’s discretion if they wish to request early review from other 
> directorates.  As a guideline, we recommend a security directorate review in 
> addition to the routing area directorate.
>  
> We are still discussing all the feedback (and there was a lot of substantive 
> feedback), so expect more from us in the coming weeks regarding the rest of 
> the feedback.
>  
> Thanks
>  
> Andrew Alston (On Behalf of the Routing AD’s)
>  
>  
> 
> Internal All Employees

[ch...@ietf.org: New version of the "Tao of the IETF" published]

[Jeffrey Haas]

A new version of the Tao of the IETF is available.  

While most Working Group participants are familiar with the Tao, it's a
worthy re-read.

-- Jeff

- Forwarded message from IETF Chair  -

Date: Fri, 9 Sep 2022 17:27:50 +0300
From: IETF Chair 
To: ietf-annou...@ietf.org
Subject: New version of the "Tao of the IETF" published

[Forwarding this on behalf of the Tao editors - Lars]

Dear all,

I am very happy to announce the new version of the Tao of the IETF [0].

This version significantly benefited from suggestions and contributions by the 
community, most notably from Rich Salz, for which I as editor am very thankful.

This publication would also not have been possible without the support of Greg 
Wood and the review of the IESG.

The IESG requested for future iterations to have smaller changes, so I intend 
to increase the publication pace. However, this also depends on the discussion 
about the future of the Tao.

Best,

Niels
Editor of the Tao

PS New suggestions are of course always welcome on tao-discuss and on Github as 
PR (https://github.com/ietf/tao/blob/main/Tao.md)

[0] https://ietf.org/tao

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

- End forwarded message -