Revision 17 has been uploaded.
On 2018-08-01, 5:28 PM, "Reshad Rahman (rrahman)" <rrah...@cisco.com> wrote:
I'm integrating Benjamin's proposal in the next rev.
Regards,
Reshad.
On 2018-07-30, 4:45 PM, "PFFC JHAAS" <jh...@pfrc.org> wrote:
Benjamin,
Your proposal would be fine. It basically says be mindful of the
relationship.
Jeff
> On Jul 30, 2018, at 10:41, Benjamin Kaduk <ka...@mit.edu> wrote:
>
> Hi Reshad,
>
>> On Thu, Jul 26, 2018 at 12:16:05AM +0000, Reshad Rahman (rrahman)
wrote:
>> Hi Benjamin and Jeff,
>>
>> Following our discussion in Montreal, would the following, or
something along these lines, be OK with you in the Security Considerations
section.
>>
>> When BFD clients are used to modify BFD configuration (as described
>> in Section 2.1), any authentication and authorization for the BFD
>> configuration changes have to take place in the BFD clients. For
>> example, if the BFD client is an IGP then the IGP SHOULD be
>> authenticated. Also, consideration should be given to the access
control of
>> the BFD clients.
>
> I can't speak for Jeff, but I think this is edging closer to the bits
he
> doesn't like. (It seems to capture the topics I had in mind just
fine,
> though.)
>
>> From our discussion in Montreal, it seemed like we might end up at
> something more like:
>
> When BFD clients are used to modify BFD configuration (as described
> in Section 2.1), the BFD clients need to be included in an analysis of
> the security properties of the BFD-using system (e.g., when
considering the
> authentication and authorization of control actions). In many cases,
BFD
> is not the most vulnerable portion of such a composite system, since
BFD is
> limited to generating well-defined traffic at a fixed rate on a given
path;
> in the case of an IGP as BFD client, attacking the IGP could cause
more
> broad-scale disruption than (de)configuring a BFD session could cause.
>
> -Benjamin
>
>
>> On 2018-07-15, 9:05 AM, "Benjamin Kaduk" <ka...@mit.edu> wrote:
>>
>>> On Wed, Jul 11, 2018 at 11:32:18AM -0400, Jeffrey Haas wrote:
>>> Benjamin,
>>>
>>>> On Wed, Jul 11, 2018 at 10:02:41AM -0500, Benjamin Kaduk wrote:
>>>> "may be overkill in some circumstances" sounds exactly like an RFC
2119
>>>> SHOULD, does it not?
>>>
>>> Putting it slightly a different way, I am always wary of trying to
embed too
>>> much operational and security wisdom in documents for the following
reasons:
>>> - What's wise in one set of circumstances may not be in another.
By being
>>> proscriptive, you may lead to implementations that lack necessary
>>> flexibility.
>>
>> In my opinion, including guidance with the supporting motivation
suffices
>> to leave flexibility for unanticipated future cases with
differing needs.
>>
>>> - You're imposing a level of fate binding between mechanisms that
may
>>> contravene desired behaviors from some operators that have split
>>> operational roles.
>>
>> If the stated motivation does not apply to operators with such
split roles,
>> do we not think they are smart enough to see that the
prerequisite is not
>> met and ignore the advice?
>>
>>> [...]
>>>> To frame the same idea in a different fashion, we have this nice
security
>>>> considerations boilerplate for YANG modules, talking about how the
usual
>>>> access methods are NETCONF/RESTCONF, with MTI secure transport of
ssh/TLS.
>>>> The scheme being described here is effectively providing a new
access
>>>> mechanism (IGP) for a subset of the YANG module,
>>>
>>> This is perhaps my personal disconnect.
>>>
>>> Much of the point of providing a common configuration grouping for
BFD for
>>> client protocols was to encapsulate, "I'm a client of BFD, here's my
>>> parameters". An implementation is free to use the "please use bfd
with
>>> these parameters for my protocol" or perhaps ignore them. But in
>>> circumstances that an operator may wish to limit access to protocol
BFD
>>> behavior, it has the existing ability in NACM to enforce its policy
on those
>>> BFD nodes within the protocol tree.
>>>
>>> What I feel you're saying is we need to call special attention to
these
>>> instantiations that may be imported by some module.
>>>
>>> What I'm confused about is why such an import is any more special
than any
>>> other import from another module.
>>
>> I've been trying to wrap my head around your explanation for the
past few
>> days, and I'm not sure I'm succeeding at it. The only reason I'm
raising
>> this point with this document is because there is text in the
document like
>> "[f]or example, when a new IGP peer is discovered, the IGP would
create a
>> BFD session to the newly discovered peer and similarly when an
IGP peer
>> goes away, the IGP would remove the BFD session to that peer."
Imagine if
>> I was writing a document about a device that controls a physical
door, and
>> the usual way to operate the device is to manually enter a PIN
while
>> physically in front of the door. If I also said "some people
expose this
>> door-unlocking device to the internet and accept unlock requests
over
>> HTTP", that would be incredibly unresponsible of me unless I
added some
>> extra qualifier. Perhaps it would be "and these people are
crazy", or
>> perhaps "but HTTP itself is insecure, so in such situations TLS
ought to be
>> used with mutual authentication, authorization checks for the
party
>> requesting unlocking, and the best practices from RFC 7525".
>>
>> So, in my head, I see this document as using a
not-quite-throwaway example
>> to make a point about the limitations of the main focus of the
document,
>> and should properly qualify the different security properties of
that
>> example. Your description above still reads to me as if it's
focusing on
>> YANG modules not specified in this document but that also use the
same BFD
>> grouping. In such a case, when the NACM applies, isn't that
still going
>> through normal management paths for that respective YANG module?
I'm still
>> trapped in a rut thinking about "received IGP packet from the
network that
>> instantiates a new IGP session; as a side effect instantiate a
BFD session
>> as well", where the incoming IGP packet is just the IGP
implementation and
>> not a "management function" per se.
>>
>> -Benjamin
>>
>>
--- Begin Message ---
A new version of I-D, draft-ietf-bfd-yang-17.txt
has been successfully submitted by Reshad Rahman and posted to the
IETF repository.
Name: draft-ietf-bfd-yang
Revision: 17
Title: YANG Data Model for Bidirectional Forwarding Detection (BFD)
Document date: 2018-08-01
Group: bfd
Pages: 79
URL: https://www.ietf.org/internet-drafts/draft-ietf-bfd-yang-17.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/
Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-yang-17
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-yang-17
Abstract:
This document defines a YANG data model that can be used to configure
and manage Bidirectional Forwarding Detection (BFD).
The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA).
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
--- End Message ---
