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
>>
>>
