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