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

[Donald Eastlake <[e-mail]>]

Hi Stephen,

Thanks for your comments. See below.

On Wed, Jul 6, 2016 at 11:37 AM, Stephen Farrell
<[e-mail]>\ wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-trill-channel-tunnel-10: No Objection
>
> ...
>
> ----------------------------------------------------------------------
> 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:-)

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

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.

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

> - 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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]