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-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sam > Hartman > Sent: 17 December 2010 20:56 > To: Sam Hartman > Cc: draft-ietf-isis-tr...@tools.ietf.org; ietf@ietf.org; sec...@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 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
