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

[Stephen Farrell <[e-mail]>]

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