Subject: [trill] Kathleen Moriarty's No Objection on draft-ietf-trill-ia-appsubtlv-09: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 06 Jul 2016 09:08:22 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-trill-ia-appsubtlv-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-ia-appsubtlv/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In the Security Considerations, I realize that this isn't the place for a
recommendation on what to use for transport, but a pointer for the
recommendation feels likes it's missing in the following text:

   However, this document merely describes a
   data format and does not provide any explicit mechanisms for securing
   that information, other than a few simple consistency checks that
   might detect some corrupted data. Security on the wire, or in
   storage, for this data is to be providing by the transport or storage
   used. For example, when transported with ESADI [RFC7357] or RBridge
   Channel [RFC7178], ESADI security or Channel Tunnel [ChannelTunnel]
   security mechanisms can be used, respectively.

Also, there is a nit in the second sentence:
s/providing/provided/

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 6 Jul 2016 13:30:52 -0400

Hi Kathleen,

Thanks for your comment. See below.

On Wed, Jul 6, 2016 at 12:08 PM, Kathleen Moriarty
<[email-masked]> wrote:
> ...

Thanks for pointing out the typo.

It seems to me that the text you quote does point to ESADI and the
Channel Tunnel draft. True, it gives them as "examples" rather than
recommendations... Saying that there should be a recommendation (or
pointer to a recommendation) of what "transport" to use seems very odd to
me. The information the IA APPsub-TLV is designed to hold is, for the
cases that motivated this document, part of some already established
transport system: either "link state" information (ESADI or perhaps
E-L1FS or E-L1CS FS-LSPs) or TRILL Pull Directory responses
(draft-ietf-trill-directory-assist-mechanisms). So I do not, for those
cases, see that you can reasonably recommends a "transport"; all you
can reasonably do is recommend the invocation of the existing security
mechanisms for the already in use transport.

Now, of course, there might be future uses not now anticipated. But
for those, it is not clear to me how to anticipate all the
non-security factors that would affect the choice of "transport". What
good would it do to say that, for example, "IPsec should be used for
transport in other cases" if it turns out the next case needed has end
end-points not identified by IP address and is really some different
paradigm like store-and-forward? If the next future use case happens
to be in a case where it is natural to use IPsec, then you should use
IPsec security. If it is as a MIME body part, then you should use MIME
security. It is is as a DNS RR, you should use DNSSEC/DNSPRIV. Saying
there should be "a recommendation on what to use for transport"
strikes as a bit like saying there should be a recommendation on what
to use for the transport of floating point numbers... But perhaps I
misunderstand you.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]