Subject: [secdir] Review of draft-ietf-bfd-vxlan-09

From: "Shawn M. Emery" <[email-masked]>
Date: Mon, 9 Dec 2019 17:51:30 -0700

Reviewer: Shawn M. Emery
Review result: Ready with nits

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This is a review of the changes since my original review of the 07 draft.
Most of my comments have been addressed, thank you.  The remaining
questions were:

1. Relating to privacy:
I believe that this section [security considerations] should also document
the security impact of deploying BFD on VXLANs for monitoring tunnel
traffic.
Which additional information, if any, can now be obtained with BFD usage?

2. Editorial:
Echo BFD is out of scope for the document, but does not describe the
reason for this or why state this at all?

They were discussed in the thread of the review but I don't know why the
draft was not updated with this information.

Shawn.
--

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Dec 2019 10:52:21 -0500

Shawn,

> Review result: Ready with nits

[...]

> Which additional information, if any, can now be obtained with BFD usage?

BFD protects transport between two systems and, in the profile envisaged in
this document, does not typically involve itself in protecting user-managed
endpoints.  (In such circumstances, they might consider standard RFC
5880/5881 BFD as a user-provisioned mechanism.)

The traffic for this mechanism is thus between two systems at the tunnel
level and only covers the information necessary to permit the BFD protocol
to execute, including any BFD security mechanisms that may be applied to
that session.  There are thus no end user privacy considerations for this
mechanism.

> reason for this or why state this at all?

This is covered by RFC 5880 section 5.  Similar to most other IETF
documents, when documenting extensions and we do not conflict with the base
behavior, we don't try to copy and paste the motivations as it waters down
the normative text.  (If we were IEEE, we'd reissue the entire suite every
time we touched something...)

Our preference is to leave it alone.

At best, we could say "See RFC 5880, section 5."

-- Jeff

---

From: "Shawn M. Emery" <[email-masked]>
Date: Tue, 10 Dec 2019 14:36:34 -0700

Hi Jeff,

Comments begin with SME...

> that session.  There are thus no end user privacy considerations for this

SME: This was not clear to me when reading the draft and think that the
text above would help in defending that there are no privacy concerns that
this specification introduces.

> At best, we could say "See RFC 5880, section 5."

SME: This was also not clear to me, as my initial investigation did not
lead me to this text.

Shawn.
--

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Dec 2019 17:00:18 -0500

Shawn,

The fundamental issue you're running into is you don't implement bfd for vxlan without also implementing base BFD (RFC 5880).  IETF specs don't typically try to spell out all considerations from the base specification in each extension.  And yes, it's a common criticism of IETF documents vs. other SDO docs such as IEEE or ITU-T.

Given this [see below]

> On Dec 10, 2019, at 4:36 PM, Shawn M. Emery <[email-masked]> wrote:
> 
> Hi Jeff,
> 
> On Tue, Dec 10, 2019 at 8:48 AM Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
> Shawn,
> 
> SME: This was not clear to me when reading the draft and think that the text above would help in defending that there are no privacy concerns that this specification introduces.

Adding in these considerations in an extension document to base BFD seems weird.

> SME: This was also not clear to me, as my initial investigation did not lead me to this text.

Understood.  But again, spelling out all such considerations from the base document in the extension document isn't very IETF.

My request would be to review RFC 5880 and see if you come to the same conclusions.

-- Jeff