Re: [trill] Stephen Farrell's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)

[Donald Eastlake <[e-mail]>]

Hi Stephen,

Thanks for your comments. See below and version -12 just posted.

On Thu, Jan 19, 2017 at 7:19 AM, Stephen Farrell
<[e-mail]> wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-trill-directory-assist-mechanisms-11: No Objection
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> - 2.6: I wondered why this was useful. Is it for cases where
> the secondary push service is differently connected or is it
> in case the primary goes down? Might be good to say.

The reasons for multiple directory servers are resilience, increase
the bandwidth of directory services, and to make them more locally
available reducing network load. It seems likely that in many cases
the directory information would come from a data center orchestration
service which would have a co-located push directory that would be
used to populate other directories. It seems like you could equally
well ask why the DNS has primary and secondary servers and does zone
transfers to populate the secondary from a primary. People generally
find this sort of thing useful in multiple-server directory
applications.

> - section 6: what security mechanism differences are there
> between the push and pull cases? Why aren't those called out
> here?  Forcing the reader to delve into the various other
> security mechanism RFCs and figure this out themselves seems
> less good.

I don't see it that way. I believe that people will choose what
combination of Push, Pull, both, or no directory they are going to use
and the like based on their operational and efficiency needs. Then
they are going to evaluate, in the context of their network/use, how
important it is to add cryptographic security. So a pointer to the
security available for each type (Push or Pull) of message answers
most implementer needs. That being said, it seems reasonable to add
that IS-IS security, available for Push messages, provides only
authentication, while RBridge Channel security, available for Pull
messages, can also provide confidentiality.

> - section 6: apologies if I asked this before (in which case I
> forget the answer;-) but how fictional/real is the crypto
> stuff with TRILL in terms of the likelihood of it being
> actually used? I ask again, as if the crypto stuff is mostly
> fictional, then I think you ought note that here, given the
> attack surface that the directory function creates.

I'm not entirely sure what you mean by the "crypto stuff with TRILL".
TRILL is built on IS-IS and IS-IS security is quite widely implemented
and deployed. The Push directory message security uses this IS-IS
security and I would expect it to be available in almost all
implementations. On the other hand, TRILL security for RBridge Channel
messages, which can be used to secure Pull directory messages, was
only fairly recently standardized in RFC 7978 so it is less widely
implemented or deployed.

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