Hi Kathleen, Thanks for your comment. See below.
On Wed, Jul 6, 2016 at 12:08 PM, Kathleen Moriarty <[email protected]> wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-trill-ia-appsubtlv-09: No Objection > > ... > > ---------------------------------------------------------------------- > 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/ 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 protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
