Re: Secdir review of draft-ietf-isis-trill

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/17/10 12:55 PM, Sam Hartman wrote:
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."

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.

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.

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


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]