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

Sam,

Thanks for your work.

Can I clarify. You wrote:

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

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: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Sam
> Hartman
> Sent: 17 December 2010 20:56
> To: Sam Hartman
> Cc: draft-ietf-isis-trill@tools.ietf.org; ietf@ietf.org; secdir@ietf.org
> Subject: Re: Secdir review of draft-ietf-isis-trill
> 
> 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
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf