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 +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] On Wed, Jul 6, 2016 at 4:08 PM, Stephen Farrell <[email protected]> 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 > > <[email protected]>\ 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 +1-508-333-2270 (cell) > > 155 Beaver Street, Milford, MA 01757 USA > > [email protected] > > > >
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
