Re: [trill] Stephen Farrell's No Objection on draft-ietf-trill-channel-tunnel-10: (with COMMENT)

Stephen Farrell <> Wed, 06 July 2016 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD14D12D63E; Wed, 6 Jul 2016 13:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gHl3oqvCwf8a; Wed, 6 Jul 2016 13:08:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BE7D12D123; Wed, 6 Jul 2016 13:08:08 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24404BE2F; Wed, 6 Jul 2016 21:08:06 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NMWSk6M9N-2A; Wed, 6 Jul 2016 21:08:04 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id F3B79BDF9; Wed, 6 Jul 2016 21:08:03 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1467835684; bh=9JOVvBiBeB+qgo1fDfHP2ARCJepdBBILIvdTyEPaooo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=BHpbE9ASvhwxwFlXUgCazuBvchV5DH7ei296ei5Y1Q12wFkSsIW+2M05A7sOPwpN8 JHt77j8E4UazWqD2W2s4Aja99tF+6CvTn6bZ+YzRZsGaNSuIRRrfjXSwQ6LPgAmL/c gNzaq1bz0Lzb3+dyjQhmnoWHre+R6Z8RaLkbQyB4=
To: Donald Eastlake <>
References: <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Wed, 6 Jul 2016 21:08:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000908000703090502030607"
Archived-At: <>
Cc:, "" <>, The IESG <>, "" <>, "" <>
Subject: Re: [trill] Stephen Farrell's No Objection on draft-ietf-trill-channel-tunnel-10: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Jul 2016 20:08:11 -0000

Hi Donald,

On 06/07/16 18:58, Donald Eastlake wrote:
> Hi Stephen,
> Thanks for your comments. See below.
> On Wed, Jul 6, 2016 at 11:37 AM, Stephen Farrell
> <>\ wrote:
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-trill-channel-tunnel-10: No Objection
>> ...
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> - The write up for this and the other trill docs on this
>> telechat talks about "directory services" but that's not
>> mentioned in any of the drafts. Pointers to RFC7067 would
>> probably have saved me a few minutes:-)
> Yes, the main directory services draft is
> draft-ietf-trill-directory-assist-mechanisms which is a fairly large
> draft and, in my estimation, almost but not quite ready for IETF LC.
> However, the security facility in the trill-channel-tunnel draft is
> pretty general and is referenced (usually Informatively) by RFC 7783,
> draft-ietf-trill-p2mp-bfd, draft-ietf-trill-address-flush, and
> draft-ietf-trill-rfc6439bis as well as by the
> trill-directory-assist-mechanisms draft.
> How about adding a sentence at the end of the Introduction, something
> like:
>    It is anticipated that these facilities will be used in support of
>    TRILL Pull Directory messages ([RFC7067], [DirectoryMechanisms])
>    and to secure a variety of RBridge Channel messages including those
>    describedmin [AddressFlush], [p2mpBFD], and [rfc6439bis].

That'd be fine, but isn't needed if the intended reader (!= me;-)
would know it already.

>> - That RFC5869 is not in the downref registry is odd.  I'd
>> say we should just add it there. It's true though that I
>> think this seems to be the first stds track doc with it as
>> normative [1] but I figure it's safe to add with no new LC
>> stuff.
>>    [1]
>> (Apologies that there's no TLS for [1] :-)
> Thanks.
>> - 4.3: Can the verifier deterministically tell from the
>> context that the keyid here refers to the derived key as
>> defined in 4.1 and not to (what I guess is) a "bare" key as
>> per RFC5310? Do you need to say that?
> The document should probably say that for Extended RBridge Channel use
> it always refers to a derived key.

Tend to agree.

>> - 4.4 or section 7: Do we know that there are no issues with
>> DTLS packets exceeding the MTU but where implementations
>> won't work, perhaps with a cert chain. DTLS does support
>> that, but do implementations that are likely to be used
>> here? If not, maybe a warning is needed. Or, do you need to
>> warn against cert based ciphersuites on the basis that
>> nobody knows what to put in certs for trill? Given that you
>> are (wisely) punting on group communication, maybe you could
>> also say that only PSK ciphersuites are to be used here for
>> now, and then also address cert based ciphersuites when you
>> get around to figuring out group keying?
> I don't know if there will be issues. I feel uncomfortable requiring
> that only pre-shared key be used -- that seems very limiting. 

Fair point.

> It is
> true that certificates for this use in TRILL are likely to be part of
> some proprietary/enterprise hierarchy within a data center or the
> like... It seems reasonable to state explicitly that specification of
> appropriate Certificate contents is out of scope for this document and
> perhaps also say that it is anticipated that it will be covered in a
> future document.

If you don't de-scope cert based schemes here then I think that does
create a need for some guidance about certs. That might be something
also needed for DTLS uses in IoT though, so good to check with those
folks (e.g. Hannes or Carsten) before/as doing that. (And we may need
an OtherName for a MAC address if there's not already one, which I

So yeah for now saying something like you suggest seems good.

>> - section 7, 3rd para: I do worry a bit about that, but
>> you've called out the risk I guess. If it were possible to
>> add more guidance as to how to defend in depth that'd be
>> good I guess.
> Well, other than making the wording a bit stronger, I'm not sure there
> is much to do.



> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA