Subject: [secdir] review of draft-ietf-isis-bfd-tlv-02

From: Stephen Kent <[email-masked]>
Date: Sat, 24 Jul 2010 16:44:40 -0400

I 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 very brief (8-page) document that is generally well 
written. It defines a TLV (an acronym not defined in the document, 
but I'm guessing type-length-value) value for use in IS-IS, for 
bidirectional forwarding detection (BFD). The abstract says that this 
TLV is needed because, in some scenarios, IS-IS fails to detect a 
forwarding plane failure based on BFD as described in 
ietf-bfd-generic]. Section 2 of this (the reviewed) document 
describes a class of scenarios in which the BFD mechanism cited above 
would not work properly, thus motivating the proposal contained here. 
The simple solution proposed here is for a router to advertise its 
ability to perform BFD on an interface via its IS-IS IIH (an acronym 
not defined in the document), hence the need to define this TLV.  My 
biggest complaint with the document overall is that it uses several 
acronyms without first defining them, an easy problem to fix.

The Security Considerations section is just one paragraph, which 
states that the addition of this feature does not adversely affect 
the security mechanism (sic) of IS-IS. I'm not questioning this 
assertion, based on reading this document, but I think a couple of 
additional sentences are needed here, to justify the assertion.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 25 Jul 2010 07:18:39 -0400

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

    Stephen> The Security Considerations section is just one paragraph,
    Stephen> which states that the addition of this feature does not
    Stephen> adversely affect the security mechanism (sic) of IS-IS. I'm
    Stephen> not questioning this assertion, based on reading this
    Stephen> document, but I think a couple of additional sentences are
    Stephen> needed here, to justify the assertion.

How about something like: This TLV does not adversely affect the
security of IS-Is. The primary consequence of using the BFD mechanism in
a case where it is not supported is incorrectly detecting a false
failure of bidirectional forwarding.  The primary consequence of not
using BFD when BFD is supported is failure to detect situations in which
bidirectional forwarding is not happening on a link. At worst, this
leads to a denial of service condition. However, a party who can
manipulate the contents of this TLV is already in a position to create
such a denial of service by disrupting IS-IS routing.

If the above paragraph is correct, I think it may go some distance to
addressing Stephen's concern.

However, I wonder how the authentication mechanisms of BFD interact with
the authentication mechanisms of IS-IS? Is it possible to get into a
situation where IS-IS is authenticated but BFD is not?  If so, that
should be discussed in the security considerations section.

--Sam

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Jul 2010 04:12:16 -0400

At 12:55 AM -0700 7/26/10, Les Ginsberg (ginsberg) wrote:
>...
>
>The mechanism introduced by this draft is used to determine when/if to
>use BFD session state as a prerequisite to forming an IS-IS adjacency
>and/or to trigger IS-IS adjacency state transitions. It does not make
>any changes to the operation of BFD itself - which I think your wording
>may unintentionally imply. How about:
>
>"The TLV defined within this document describes an addition to the IS-IS
>Hello protocol. Inappropriate use of this TLV could prevent an IS-IS
>adjacency from forming or lead to failure to detect bidirectional
>forwarding failures - each of which is a form of denial of service.
>However, a party who can
>such a denial of service by disrupting IS-IS routing in other ways."
>

That text is much better. I think it is also worth including a 
sentence, as you did later in your message, noting that the use of 
this new TLV in the IS-IS hello exchange is independent of the use of 
authentication for that exchange or for BFD.

Steve

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Jul 2010 04:16:29 -0400

I'm fine with your changes to my text; I think it improves and clarifies
things.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 26 Jul 2010 00:55:06 -0700

Sam/Stephen -

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Sunday, July 25, 2010 4:19 AM
> To: Stephen Kent
> Cc: [email-masked]; Les Ginsberg (ginsberg); [email-masked];
> Stewart Bryant (stbryant); Chris Hopps (chopps)
> Subject: Re: [secdir] review of draft-ietf-isis-bfd-tlv-02
> 

??

> the authentication mechanisms of IS-IS? 

They do not interact.

> Is it possible to get into a

It is possible to use BFD in conjunction w IS-IS today - and of course
folks are actually doing that. The mechanism introduced here does not
change that - it just allows the protocol to operate correctly when
IS-IS PDUs and IP/IPv6 packets do not share fate. I don't see that we
have introduced any change in the way authentication is used/not used
for either IS-IS or BFD - nor have we introduced the use of BFD in
conjunction w IS-IS. So I don't see that discussing the point you raise
is needed.

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 26 Jul 2010 07:43:40 -0700

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Monday, July 26, 2010 1:12 AM
> To: Les Ginsberg (ginsberg)
> Cc: Sam Hartman; [email-masked]; [email-masked]; Stewart Bryant
> (stbryant); Chris Hopps (chopps)
> Subject: RE: [secdir] review of draft-ietf-isis-bfd-tlv-02
> 
> >"The TLV defined within this document describes an addition to the
IS-
> IS

OK - perhaps:

"The TLV defined within this document describes an addition to the IS-IS
Hello protocol. Inappropriate use of this TLV could prevent an IS-IS
adjacency from forming or lead to failure to detect bidirectional
forwarding failures - each of which is a form of denial of service.
However, a party who can manipulate the contents of this TLV is already
in a position to create such a denial of service by disrupting IS-IS
routing in other ways. Use of authentication by IS-IS and/or by BFD is
not altered by this document."

??

   Les

---

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Jul 2010 06:29:10 -0400

>not altered by this document."

I'm comfortable with that text.

Steve