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

Erik Nordmark <> Fri, 17 December 2010 21:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FA7B3A69FC; Fri, 17 Dec 2010 13:59:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.475
X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dcklKfN9geib; Fri, 17 Dec 2010 13:59:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 80DDF3A69FB; Fri, 17 Dec 2010 13:59:50 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id oBHM1Xft007102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2010 14:01:35 -0800
Message-ID: <>
Date: Fri, 17 Dec 2010 14:01:36 -0800
From: Erik Nordmark <>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv: Gecko/20101025 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: Sam Hartman <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 17 Dec 2010 14:07:10 -0800
Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Dec 2010 21:59:51 -0000

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."


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 

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.