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

[Sam Hartman <[e-mail]>]

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