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