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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 06 Jul 2016 08:37:30 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-trill-channel-tunnel-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-channel-tunnel/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 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:-)

- 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] http://www.arkko.com/tools/allstats/citations-rfc5869.html

(Apologies that there's no TLS for [1] :-)

- 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? 

- 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?

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

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 6 Jul 2016 13:58:20 -0400

Hi Stephen,

Thanks for your comments. See below.

On Wed, Jul 6, 2016 at 11:37 AM, Stephen Farrell
<[email-masked]>\ wrote:
> ...

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

> (Apologies that there's no TLS for [1] :-)

Thanks.

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

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

> add more guidance as to how to defend in depth that'd be

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
 [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 6 Jul 2016 21:08:03 +0100

Hi Donald,

>    describedmin [AddressFlush], [p2mpBFD], and [rfc6439bis].

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

> it always refers to a derived key.

Tend to agree.

> that only pre-shared key be used -- that seems very limiting. 

Fair point.

> It is

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
forget;-)

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

> Well, other than making the wording a bit stronger, I'm not sure there

Yep.

Cheers,
S.