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

[Erik Nordmark <[e-mail]>]

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