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

[Donald Eastlake <[e-mail]>]

Hi Stephen,

Version -11 has been posted which is intended to improve the draft in light
of your COMMENT.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

On Wed, Jul 6, 2016 at 4:08 PM, Stephen Farrell <[e-mail]>
wrote:

>
> 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
> > <[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'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] 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.
>
> 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
> forget;-)
>
> 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.
>
> Yep.
>
> Cheers,
> S.
>
> >
> > Thanks,
> > Donald
> > ===============================
> >  Donald E. Eastlake 3rd   [phone] (cell)
> >  155 Beaver Street, Milford, MA 01757 USA
> >  [e-mail]
> >
>
>