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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Haas-2
[Speaking as an individual contributor]

Authors,

Attached, please find an rfcdiff containing some suggested edits to your
draft.  The intent is to try to add clarity to the document.  If you would
find it helpful, I can also forward a patch vs. the published -01 xml.

---

Additionally, there are several points of discussion for you and perhaps the
Working Group about this proposal:

The changes recommended in section 2 are clear, but difficult to see what
content each change brings.  IETF has a mixed culture about how to implement
such changes in a document.  This draft does so by copy, paste, and change.
If we can collectively find a better way to highlight the differences
without being so wordy, that would be good.

Alternatively, I know some people will be thrilled with the format you have
chosen.  :-)

---

In section 3, the proposal effectively says that the BFD speaker is
originating BFD Control packets in the Echo Packet mode.  Since RFC 5880/5881
keeps the details about how Echo packets are made out of scope, but does
provide some guidance for security, this is acceptable.

I would suggest highlighting that the validation procedures of RFC 5880 are
used.  The intent appears to be "re-use existing BFD Control procedure as
much as possible", which means re-use of code.  Good!  However, this leads
to some interesting issues.

One example is that since a BFD speaker is "hearing itself" rather than
having the remote device actually speaking BFD, some things are wrong.  As
an example, the Discriminator procedures in the BFD Async mode can't apply.
The remote won't pick its own and swap it!  I'd thus recommend some text
about this.

RFC 5880, section 5, has the following to say about authentication:
:   Some form of authentication SHOULD be included, since Echo packets
:   may be spoofed.

Some procedural text related to authentication and the contents of the
packets is needed.

The desired min TX and required min RX intervals should be populated with
something, even if it's 1 second.  And perhaps some advice that we're
ignoring the values in these fields.

---

Your last set of changes in section 2 attempts to adjust the text covering
sending Echo packets.  When the implementation transitions to sending them
at the desired echo speed is a little ambiguous since the role of Control
packets is on the Echo port and in Echo packets.

One possible solution is that the Echo rate is not used until the BFD state
machine moves to the Up stage as per normal RFC 5880 procedures.  However,
that involves running the state machine from its usual slow rate of 1 second
until we transition to Up, and reverting to the slow rate when it goes to
Down/AdminDown.

This text will be tricky to do since we're blending the Control mode in the
Echo packets.

A strong goal of this is what happens when the remote is not echoing packets
back to us properly.  We do not want the BFD echo sender to transition
directly to a denial-of-service condition, especially since the TTL is set
to 255.  The usual slow rate until Up at least mitigates the sender's role
in this problem.

Note that the TTL receive check on the receiver will be at least 254 due to
the loop.  This reduces the effectiveness of GTSM, and potentially is an
issue for the loop procedure.

---

Does this mechanism ever go AdminDown?  What does it do, if so?

---

Suggestion: Move the following text in some form to the top of section 3:

:   After receiving the BFD Echo packets sent from device A, the one-hop-
:   away BFD peer device B immediately loops them back by normal IP
:   forwarding, this allows device A to rapidly detect a connectivity
:   loss to device B.

Being able to do this is a requirement for the feature, and the easy one to
articulate.  It provides the motivations for the rest of the section.

---

Security Considerations:

The URPF comments in the security considerations is really intended to say
"you can't do urpf for this feature".  It might be easy to just say that
more directly.

The requirement for this feature is that the receiver is willing to loop UDP
packets on port 3785.  In the simplest possible implementation, this can
become an open reflector attack and is probably one of the larger security
considerations our Transport and Security Area Directors and their
Directorates will flag.

There are two mitigations that can help with this, although it's an open
question whether the host stacks supplying the loop beheaviors can support
them:
- A packet SHOULD NOT be looped unless it has a TTL of 255.
- A packet being looped MUST NOT reset the TTL to 255, and SHOULD use a TTL
  of 254.  The motivation for this is firstly to respect GTSM procedures on
  reception and prevent remote attackers from exploiting the loop.  This
  should be able to be implemented using a firewall at the very least.
  Secondly, retransmiting with a fresh TTL of 255 can potentially cause a
  set of looping devices to infinitely loop traffic.  A TTL of 254 is the
  largest TTL that can prevent such infinite loops.  A lower TTL widens the
  window for targeting attack traffic to the BFD speaker originating the
  Echo traffic.

---

Comment to note for later purposes: the BFD state variables for the yang
module will need to be defined for these changes.  Oddly, we never got
around to doing a central IANA registry for such things.

-- Jeff

draft-ietf-bfd-unaffiliated-echo-jhaas-from-01.diff.html (54K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

xiao.min2
Hi Jeff,







Many thanks for your insightful review and comments


Please see inline my responses tagged with <XM>.


Sorry for the late response.






Best Regards,


Xiao Min



原始邮件



发件人:JeffreyHaas
收件人:[hidden email];
抄送人:[hidden email];
日 期 :2021年04月06日 05:41
主 题 :Comments on draft-ietf-bfd-unaffiliated-echo-01


[Speaking as an individual contributor]
 
Authors,
 
Attached, please find an rfcdiff containing some suggested edits to your
draft.  The intent is to try to add clarity to the document.  If you would
find it helpful, I can also forward a patch vs. the published -01 xml.
 <XM> I find it very helpful. Much appreciated if you can forward a patch. If you're interested to be co-author of this draft, please let the authors know.
---
 
Additionally, there are several points of discussion for you and perhaps the
Working Group about this proposal:
 
The changes recommended in section 2 are clear, but difficult to see what
content each change brings.  IETF has a mixed culture about how to implement
such changes in a document.  This draft does so by copy, paste, and change.
If we can collectively find a better way to highlight the differences
without being so wordy, that would be good.
 <XM> I did some study on this issue. Currently what I can suggest is to add some flags like <Del> </Del> <Add> </Add> into the text, avoiding copy paste. Of course it would be better if we can find a way to add strikethrough and italic/bold text.
Alternatively, I know some people will be thrilled with the format you have

chosen.  :-)
 
---
 
In section 3, the proposal effectively says that the BFD speaker is
originating BFD Control packets in the Echo Packet mode.  Since RFC 5880/5881
keeps the details about how Echo packets are made out of scope, but does
provide some guidance for security, this is acceptable.
 <XM> Thanks for your understanding.



I would suggest highlighting that the validation procedures of RFC 5880 are
used.
<XM> Will add some text as you suggest.

The intent appears to be "re-use existing BFD Control procedure as

much as possible", which means re-use of code.  Good!  However, this leads
to some interesting issues.
 
One example is that since a BFD speaker is "hearing itself" rather than
having the remote device actually speaking BFD, some things are wrong.  As
an example, the Discriminator procedures in the BFD Async mode can't apply.
The remote won't pick its own and swap it!  I'd thus recommend some text
about this.
 <XM> Will add some text as you recommend.

RFC 5880, section 5, has the following to say about authentication:

:   Some form of authentication SHOULD be included, since Echo packets
:   may be spoofed.
 
Some procedural text related to authentication and the contents of the
packets is needed.
 <XM> Will add some text as you require.

The desired min TX and required min RX intervals should be populated with

something, even if it's 1 second.  And perhaps some advice that we're
ignoring the values in these fields.
 <XM> Will add some text as you suggest.

---


Your last set of changes in section 2 attempts to adjust the text covering
sending Echo packets.  When the implementation transitions to sending them
at the desired echo speed is a little ambiguous since the role of Control
packets is on the Echo port and in Echo packets.
 
One possible solution is that the Echo rate is not used until the BFD state
machine moves to the Up stage as per normal RFC 5880 procedures.  However,
that involves running the state machine from its usual slow rate of 1 second
until we transition to Up, and reverting to the slow rate when it goes to
Down/AdminDown.
 <XM> Agree to your proposed solution which follows the normal RFC 5880 procedures.
Will add some text on that.

This text will be tricky to do since we're blending the Control mode in the

Echo packets.
<XM> Yes, you're right. Will provide some text for your further review.


A strong goal of this is what happens when the remote is not echoing packets
back to us properly.  We do not want the BFD echo sender to transition
directly to a denial-of-service condition, especially since the TTL is set
to 255.  The usual slow rate until Up at least mitigates the sender's role
in this problem.
 
Note that the TTL receive check on the receiver will be at least 254 due to
the loop.  This reduces the effectiveness of GTSM, and potentially is an
issue for the loop procedure.
 
---
 
Does this mechanism ever go AdminDown?  What does it do, if so?
 <XM> Prefer to leave AdminDown out of Unaffiliated BFD Echo, in which scenario AdminDown effectively means removal of BFD echo session.
If you agree, we'll add some text on it.

---
 
Suggestion: Move the following text in some form to the top of section 3:
 
:   After receiving the BFD Echo packets sent from device A, the one-hop-
:   away BFD peer device B immediately loops them back by normal IP
:   forwarding, this allows device A to rapidly detect a connectivity
:   loss to device B.
 
Being able to do this is a requirement for the feature, and the easy one to
articulate.  It provides the motivations for the rest of the section.
 <XM> Will do as you suggest

---


Security Considerations:
 
The URPF comments in the security considerations is really intended to say
"you can't do urpf for this feature".  It might be easy to just say that
more directly.
 <XM> OK, will tweak the text to make it concise.

The requirement for this feature is that the receiver is willing to loop UDP

packets on port 3785.  In the simplest possible implementation, this can
become an open reflector attack and is probably one of the larger security
considerations our Transport and Security Area Directors and their
Directorates will flag.
 
There are two mitigations that can help with this, although it's an open
question whether the host stacks supplying the loop beheaviors can support
them:
- A packet SHOULD NOT be looped unless it has a TTL of 255.
- A packet being looped MUST NOT reset the TTL to 255, and SHOULD use a TTL
  of 254.  The motivation for this is firstly to respect GTSM procedures on
  reception and prevent remote attackers from exploiting the loop.  This
  should be able to be implemented using a firewall at the very least.
  Secondly, retransmiting with a fresh TTL of 255 can potentially cause a
  set of looping devices to infinitely loop traffic.  A TTL of 254 is the
  largest TTL that can prevent such infinite loops.  A lower TTL widens the
  window for targeting attack traffic to the BFD speaker originating the
  Echo traffic.
 <XM> Agree to the two mitigations, it seems work, although I have no idea whether the host stacks can support them.
Will add text on it, and then ask for more review and discussion.
---


Comment to note for later purposes: the BFD state variables for the yang
module will need to be defined for these changes.  Oddly, we never got
around to doing a central IANA registry for such things.
 
-- Jeff