Subject: [secdir] Secdir review of draft-ietf-isis-trill

From: Sam Hartman <[email-masked]>
Date: Tue, 14 Dec 2010 11:09:20 -0500

Please treat these as normal last call comments.

I found the introduction to draft-ietf-isis-trill inadequate. I'm
familiar with the base concepts behind TRILL, roughly understand what
was going on and followed the chartering discussions of the WG fairly
closely.  I have read the requirements document but have not read the
protocol document.  In an ideal world this document would be
significantly easier to follow; I suspect that after reading the
protocol document I'd still find this a bit choppy.
However, I understand  that sometimes you can only spend so much time on
a spec and sometimes you reach the point where if someone isn't willing
to jump in and volunteer a lot of hours to add clarity, good enough is
good enough.

This document claims that it adds no new security considerations to
IS-IS.  That's true.  However, TRILL is a new protocol--completely new.
It re-uses IS-IS as a building block, but if I were a security AD I'd
still insist that TRILL meet our current standards for security,
including a strong mandatory-to-implement security mechanism and (where
appropriate) automated key management.

I definitely think that this specification should at least document how
IS-IS+TRILL fall short of standards we'd require for a new protocol
today.  The big area I can think of is replay handling for hello
packets, which I suspect leads to a DOS.  If we had more success with
multicast key management we'd probably also require automated key
management for a protocol like this. However,we don't, so I think that
the RFC 4107 analysis would conclude that manual key management is
acceptable under the multicast exception.

I suspect the sec ADs will not actually require a solution even though
it is a new protocol. I think that's a mistake, but I also don't have a
lot of time to spend on TRILL, and I'd definitely rather see it get
published than bogged down. I think documenting how IS-IS security
interacts with TRILL security and IETF security BCPs should only take a
relatively short time.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Dec 2010 15:55:51 -0500

Hi.  I've been asked by the trill authors to clarify what I meant by my
secdir review.

That's certainly fair.

I think there are two issues.

The first is that I think that draft-ietf-isis-trill does an adequate
job of discussing the security implications of IS-IS on trill.  I've
read the security considerations section of
draft-ietf-trill-rbridge-protocol and I think it doesn't do so either.

However, it comes very close.  If I understand Is-IS security correctly,
the only attack that we would expect a routing protocol to deal with
that it does not is replays. (IS-Is is no worse than anything else
here.)  The impact of replays is a denial of service.  If I'm
understanding section 6.2 of draft-ietf-trill-rbridge-protocol
correctly, similar denial of service attacks are also possible with
trill-specific messages.

If my understanding of the impact of IS-IS security (even with
authentication) is sufficient, I think this concern could be addressed
by adding a sentence to the security considerations section of
draft-ietf-isis-trill saying something like "Even when the IS-IS
authentication is used, replays of IS-IS packets can create
denial-of-service conditaions; see RFC 6039 for details. These issues
are similar in scope to those discussed in section 6.2 of
draft-ietf-trill-rbridge-protocol, and the same mitigations may apply."

I have a second large issue with the way we've handled trill.  First I'd
like to compliment the authors of draft-ietf-trill-rbridge-protocol,
particularly on the security considerations section, but the document
quality of other sections of that document I've looked at is high.
They've done a good job of describing what they've done and as far as I
can tell delivering what they've said they would deliver.

However, something went wrong somewhere.  We have some standards that
we've agreed to as a community for the security of new work we do. It's
my opinion that trill does not meet those standards. The document
doesn't claim it does.

I think that was wrong, however the mistake was in the review of RFC
5556 (the TRILL problem statement), which clearly sets out what TRILL
was going to do.  I believe I was on the IESG at a time when that
document was reviewed, so I especially don't have room to complain here.

So, actually even were I on the IESG, I would not hold up the protocol
over this issue.

Looking forward to future work, though, I think we should be more
consistent about applying our community standards to work we charter. If
those standards are wrong, let's revise them.  No, TRILL should not have
been forced to solve the ethernet control plane security
problem. However TRILL should have had a security mechanism that meets
current standards so that when the ethernet control plane is updated
TRILL never ends up being the weakest link.  As best I can tell, TRILL
does meet the security goals stated in its problem statement.

Also, my comment about document quality was never intended to be
blocking. While I don't believe draft-ietf-isis-trill is of as high
quality as draft-ietf-trill-rbridge-protocol, I did manage to understand
it without the rbridge-protocol document. The authors claim that should
not be requried; I think if I had looked at the rbridge-protocol
document first I would have concluded that it was more clear than
isis-trill, although I think it's also true that I would have been less
bothered.  Either way, I did manage to follow both documents.

--Sam

---

From: Adrian Farrel <[email-masked]>
Date: Fri, 17 Dec 2010 21:24:38 +0000

Sam,

Thanks for your work.

> draft-ietf-trill-rbridge-protocol and I think it doesn't do so either.

I you have one positive and one negative statement.
I think you meant them to both be negative.
Perhaps you could confirm.

Cheers,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam
> Hartman
> Sent: 17 December 2010 20:56
> To: Sam Hartman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Secdir review of draft-ietf-isis-trill
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Dec 2010 16:33:30 -0500

>>>>> "Adrian" == Adrian Farrel <[email-masked]> writes:

    Adrian> Sam, Thanks for your work.

    Adrian> Can I clarify. You wrote:

    >> job of discussing the security implications of IS-IS on trill.
    >> I've read the security considerations section of

    Adrian> I you have one positive and one negative statement.  I think
    Adrian> you meant them to both be negative.  Perhaps you could
    Adrian> confirm.

You are correct.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 17 Dec 2010 14:01:36 -0800

Sam,

Adding just this sentence to draft-ietf-isis-trill (the code point 
document) seems odd. Your comment is really a comment on the security of 
IS-IS, and not specific to TRILL and unrelated to the code points.

If we need to point out this IS-IS issue the right place to do that 
would have been in draft-ietf-trill-rbridge-protocol; we shouldn't make 
draft-ietf-isis-trill a random collection of (editorial) corrections 
against the IS-IS spec or the TRILL spec.

I don't know if an RFC-ed note for draft-ietf-trill-rbridge-protocol 
makes sense at this late date (close to a year after the IESG approved 
it). But one could add a sentence to the second paragraph in section 6 
pointing specifically at replay attacks and RFC 6039.

> does meet the security goals stated in its problem statement.

Do you have a concrete case where TRILL would end up being the weakest 
link?

We designed the protocol so that ESADI can have higher learning 
confidence level that learning from data frames. This was to ensure that 
if e.g., 802.1x or some future technology is used at the edge to 
autenticate stations, we can give that higher confidence thus ensure 
that TRILL benefits from that additional security.

I don't understand the implications of your reference to current 
standards. Are you saying that if TRILL was chartered today, its charter 
would say that it "MUST NOT reuse IS-IS or OSPF since those are not 
sufficiently secure"?
Such a stance doesn't make sense to me, since we want to leverage 
existing protocols while we improve the security of those existing 
protocols, instead of prohibiting re-use.

Regards,
    Erik

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Dec 2010 22:45:54 -0500

>>>>> "Erik" == Erik Nordmark <[email-masked]> writes:

    Erik> Adding just this sentence to draft-ietf-isis-trill (the code
    Erik> point document) seems odd. Your comment is really a comment on
    Erik> the security of IS-IS, and not specific to TRILL and unrelated
    Erik> to the code points.

I don't care much where the text goes.  I'm happy if you provide an rfc
editor note for draft-ietf-trill-rbridge-protocol if you like that
approach better.  However, as I read draft-ietf-isis-trill, it defines
the interface between TRILL and IS-IS.  In my mind, that's where the
security consideration appears.  You're re-using a component that isn't
up to our current standards--we know that; we're working on it in
KARP. However in doing that, you need to document the security
considerations for your protocol.  Since you have a document that
specifically is the interface between your protocol and the component
you are re-using,that seems like the best place to do the documentation
work.

however, in decreasing order of priority, I want to call out my concern
that we need to be far more careful about what we expect in terms of
security from future work we charter and that we should document the
specific interactions between IS-IS and TRILL.  While I have expressed
an opinion above on where I think that documentation should go, feel
free to put it where you think is most correct.

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 19 Dec 2010 13:16:47 -0500

My apologies for responding slowly, I was traveling.

If it is tolerable to people, I do not mind adding the two sentences
requested by Sam to the isis-trill draft.

Thanks,
Donald

PS: It appears to me that the same considerations apply to
draft-ietf-isis-ieee-aq.

---

From: Radia Perlman <[email-masked]>
Date: Sun, 19 Dec 2010 11:57:38 -0800

No objections.

Radia

On Sun, Dec 19, 2010 at 10:16 AM, Donald Eastlake <[email-masked]> wrote:
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Dec 2010 11:42:32 -0500

>>>>> "Radia" == Radia Perlman <[email-masked]> writes:

    Radia> No objections.  Radia

Can I get someone to confirm that the text in the proposed sentences is
substantially true?
I think so but I'm not an IS-IS expert.

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 20 Dec 2010 13:43:03 -0500

Hi,

> I think so but I'm not an IS-IS expert.

LSPs have sequences number, etc., and are idempotent. I think only
Hellos have the potential replay Denial of Service problem. So I would
suggest changing to:

"Even when the IS-IS
authentication is used, replays of Hello packets can create
denial-of-service conditaions; see RFC 6039 for details. These issues
are similar in scope to those discussed in section 6.2 of
draft-ietf-trill-rbridge-protocol, and the same mitigations may apply."

Thanks,
Donald

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Dec 2010 13:50:38 -0500

>>>>> "Donald" == Donald Eastlake <[email-masked]> writes:

    Donald> Hi,
    Donald> On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman <[email-masked]> wrote:
    >> Can I get someone to confirm that the text in the proposed
    >> sentences is substantially true?  I think so but I'm not an IS-IS
    >> expert.

    Donald> LSPs have sequences number, etc., and are idempotent. I
    Donald> think only Hellos have the potential replay Denial of
    Donald> Service problem. So I would suggest changing to:

    Donald> "Even when the IS-IS authentication is used, replays of
    Donald> Hello packets can create denial-of-service conditaions; see
    Donald> RFC 6039 for details. These issues are similar in scope to
    Donald> those discussed in section 6.2 of
    Donald> draft-ietf-trill-rbridge-protocol, and the same mitigations
    Donald> may apply."

Based on my understanding your correction is accurate; thanks.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 20 Dec 2010 19:05:01 +0000

On 20/12/2010 18:43, Donald Eastlake wrote:
> Hi,
>
> On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman<[email-masked]>  wrote:
>>>>>>> "Radia" == Radia Perlman<[email-masked]>  writes:
... as I recall from discussions with the ISIS WG the changes that were 
made to ISIS for TRILL make it more vulnerable to a hello attack than 
vanilla ISIS. This I understand is because there is more work to be done 
in processing a TRILL hello. Is that correct?

- Stewart

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 20 Dec 2010 16:58:47 -0500

Hi,

On Mon, Dec 20, 2010 at 2:05 PM, Stewart Bryant <[email-masked]> wrote:
> ... as I recall from discussions with the ISIS WG the changes that were made
> to ISIS for TRILL make it more vulnerable to a hello attack than vanilla
> ISIS. This I understand is because there is more work to be done in
> processing a TRILL hello. Is that correct?

I think we are talking about Denial of Service due to replay of old
Hellos screwing up the state. This is unrelated to the work required
to process a Hello.

It is true that some processing is required for IS-IS LAN Hellos. One
reason for having a protocol like BFD is that you can send BFD
messages more frequently because they take less processing than
Hellos.  But I don't see why there would be that much difference
between the work involved in processing a TRILL LAN Hello and a Layer
3 IS-IS LAN Hello.

Thanks,
Donald