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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf