Subject: Kathleen Moriarty's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS)

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 02 May 2016 12:36:24 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-bfd-seamless-base-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be pretty easy to address.  In the security consideration
section, the following recommendation appears:

 o  SBFDReflector MUST NOT look at the crypto sequence number before
      accepting the packet.

Could you please add text to say what happens (what attacks are possible)
if this is looked at?  There is nothing to stop the crypt sequence number
from being looked at, right?  Is there a way to actually prevent that?

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 3 May 2016 05:18:23 +0530

Hi Kathleen,

SBFD is state-less. The SBFDReflector is NOT maintaining any BFD peer
state, and is thus incapable of doing the crypto-sequence checks. It has no
idea of last sequence number that it had seen from a BFD peer, and hence
CANNOT compare the new sequence number. Its for this reason that we mandate
that the reflectors MUST NOT look at the sequence numbers.

We cant prevent a peer from looking at the sequence number -- thats an
implementation specific issue. The implementation is violating the
standard. Not sure what we can do to prevent that.

Does this help?

Cheers, Manav

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 3 May 2016 00:04:30 +0000

Kathleen,

> On May 2, 2016, at 7:48 PM, Manav Bhatia <[email-masked]> wrote:
> 
> Hi Kathleen,
> 
> DISCUSS:
> SBFD is state-less. The SBFDReflector is NOT maintaining any BFD peer state, and is thus incapable of doing the crypto-sequence checks. It has no idea of last sequence number that it had seen from a BFD peer, and hence CANNOT compare the new sequence number. Its for this reason that we mandate that the reflectors MUST NOT look at the sequence numbers.
> 

Further to this, the SBFDReflector can be receiving S-BFD packets from multiple SBFDInitiators. Hence, the authentications can be used from BFD but not the sequence numbers.

> We cant prevent a peer from looking at the sequence number -- thats an implementation specific issue. The implementation is violating the standard. Not sure what we can do to prevent that.
> 
> Does this help?
> 

We could also explain the rational behind this requirement a bit better. Would that help?

Thanks,

— Carlos.

---

From: [email-masked]
Date: Mon, 2 May 2016 20:34:18 -0400

Hi,

Thanks for the quick responses.  See inline 

Sent from my iPhone

> On May 2, 2016, at 8:04 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
> 
> Kathleen,
> 
Yes, that would be helpful.  I'm glad to see that this is not an issue.

Thanks,
Kathleen

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 3 May 2016 00:49:21 +0000

Hi, Kathleen,

> On May 2, 2016, at 8:34 PM, [email-masked] wrote:
> 
> Hi,
> 
> On May 2, 2016, at 8:04 PM, Carlos Pignataro (cpignata) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Kathleen,
>> 
>>> On May 2, 2016, at 7:48 PM, Manav Bhatia <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Kathleen,
>>> 
>>> DISCUSS:

Indeed — thanks. I added the following, ready in our working copy:

@@ -916,7 +916,10 @@
       configured.

    o  SBFDReflector MUST NOT look at the crypto sequence number before
-      accepting the packet.
+      accepting the packet.  This is because the SBFDReflector does not
+      maintain S-BFD peer state, and because the SBFDReflector can
+      receive S-BFD packets from multiple SBFDInitiators.  Consequently,
+      BFD authentication can be used but not the sequence number.

    o  SBFDReflector MAY look at the Auth Key ID in the incoming packet
       and verify the authentication data.

Thanks,

— Carlos.

---

From: [email-masked]
Date: Mon, 2 May 2016 20:54:48 -0400

Sent from my iPhone

> On May 2, 2016, at 8:49 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
> 
> Hi, Kathleen,
> 

Excellent, thank you.  I'll move it to a comment in the morning for the shepherd & AD to track when approving the draft.

Best regards,
Kathleen