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

Shawn,

Thank you for closing the loop on this point.  I believe there are no further open issues raised by security directorate review.

-- Jeff

> On Jan 28, 2020, at 12:48 PM, Shawn M. Emery <semery@uccs.edu> wrote:
> 
> Jeff,
> 
> Thank you for your follow up.  I'm fine with this draft given the fact that BFD for vxlan does not raise any additional privacy concerns over the base specification.
> 
> Shawn.
> --
> 
> On Tue, Jan 28, 2020 at 5:46 AM Jeffrey Haas <jhaas@pfrc.org <mailto:jhaas@pfrc.org>> wrote:
> Shawn,
> 
> Since we are clearing through open discuss/comments from the IESG, I'd
> appreciated a response to the final point in this mail chain:  Basically,
> while your concern is that BFD for vxlan doesn't spell out privacy
> considerations, your issue is with the core of BFD.  Thus, it's a poor fit
> for a simple extension document to contain the privacy considerations.
> 
> -- Jeff
> 
> On Tue, Dec 10, 2019 at 05:00:18PM -0500, Jeffrey Haas wrote:
> > 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 <semery@uccs.edu <mailto:semery@uccs.edu>> wrote:
> > > 
> > > Hi Jeff,
> > > 
> > > Comments begin with SME...
> > > 
> > > On Tue, Dec 10, 2019 at 8:48 AM Jeffrey Haas <jhaas@pfrc.org <mailto:jhaas@pfrc.org> <mailto:jhaas@pfrc.org <mailto:jhaas@pfrc.org>>> wrote:
> > > Shawn,
> > > 
> > > On Mon, Dec 09, 2019 at 05:51:30PM -0700, Shawn M. Emery wrote:
> > > > Reviewer: Shawn M. Emery
> > > > Review result: Ready with nits
> > > 
> > > [...]
> > > 
> > > > 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?
> > > 
> > > 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.
> > > 
> > > 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.
> > 
> > >  
> > > > 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?
> > > 
> > > 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."
> > > 
> > > 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
> > 
> > > 
> > > Shawn.
> > > --
> > 
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org <mailto:secdir@ietf.org>
> https://www.ietf.org/mailman/listinfo/secdir <https://www.ietf.org/mailman/listinfo/secdir>
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview <http://tools.ietf.org/area/sec/trac/wiki/SecDirReview>