Re: [trill] Shepherd write-up for draft-ietf-trill-channel-tunnel-06.txt

[Donald Eastlake <[e-mail]>]

Hi Sue,

On Thu, Aug 13, 2015 at 7:24 PM, Susan Hares <[e-mail]> wrote:
> Donald:
>
>
> One other thing for this draft.  The NITS indicates that RFC 3060 and
> RFC5869 are informative drafts that you have indicated as normative.   This
> NIT will cause problems in the IETF review.

Well, this needs to be mentioned in the Shepherd review and in the
IETF Last Call but other than that, I don't see why, in this case, it
will cause any problem. It is very common for cryptographic algorithms
to be documented in Informational RFCs because the IETF does not have
change control over them.

> If you intend these two types security algorithms to be utilized, it is
> important to put something in the security section of the draft that warns
> people regarding the use of informative drafts.

I can't recall seeing such language. Can you point to an example? Why
would it matter to anyone implementing the draft?

HMAC is probably the strongest example of such a downref. It is
referenced by 235 RFCs many of which have normative references. See
http://datatracker.ietf.org/doc/rfc2104/referencedby/
I looked at a few of these that are recent and didn't see any explicit
mention of RFC 2104 being Informational. They typically just say
things like "The HMAC authentication mode defined in [RFC2104] is
used."

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

> 872        [RFC3610] - Whiting, D., Housley, R., and N. Ferguson, "Counter with
> 873              CBC-MAC (CCM)", RFC 3610, September 2003, <http://www.rfc-
> 874              editor.org/info/rfc3610>.
>
>
> 888        [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-
> 889              Expand Key Derivation Function (HKDF)", RFC 5869, May 2010,
> 890              <http://www.rfc-editor.org/info/rfc5869>.
>
>
> Sue
>
>
>
> From: Donald Eastlake [mailto:[e-mail]]
> Sent: Thursday, August 13, 2015 6:04 PM
> To: Susan Hares
> Cc: [e-mail]; Jon Hudson; [e-mail]
> Subject: Re: [trill] Shepherd write-up for
> draft-ietf-trill-channel-tunnel-06.txt
>
>
>
> Hi Sue,
>
>
>
> Actually I take back one thing I said earlier. See below at <dee3>.
>
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>
>
>
> On Thu, Aug 13, 2015 at 4:40 PM, Susan Hares <[e-mail]> wrote:
>
> ...
>
>
>
> p. 9 figure 3.1 – Do you want the text in the possible security information
> to be changed from:
>
>
>
> from:
>
>
>
> RBridge-channel (0x8946) | CHV=0 | channel Protocol
>
>
>
> to:
>
>
>
> RBridge-channel (0x8946) | CHV=0 | Tunnel Protocol = TBD
>
>
>
> Yup, good catch.
>
>
>
> <dee3> Not really. At first glance, you seemed to be correct and I thought
> so but looking at this more closely, what is going on is that you have an
> RBridge Channel protocol message nested inside an RBridge Channel Tunnel
> message. So looking at figure 3.1, in the first line we have the TBD RBridge
> Channel Tunnel protocol number. This is followed by the rest of that RBridge
> Channel message header. Then, the nested RBridge Channel protocol message
> starts with a 2nd instance of the RBridge Channel Ethertype. The protocol
> number for this nested RBridge Channel message could be any valid RBridge
> Channel protocol number. I've changed the figure to look like the following
> so where it used to say "channel Protocol" it now says "Nested Channel
> Protocol" and where it said "Channel Protocol Specific Data ..." it now says
> "Nested Channel Protocol Specific Data ...". Also, this isn't actually data
> inside the Possible Security Information. The Possible Security Information
> is variable length material that is only present if the SType (Security
> Type) field is non-zero.
>
>
>
>                      1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
>
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |    RBridge-Channel (0x8946)   | CHV=0 | Tunnel Protocol = TBD |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |          Flags        |  ERR  | SubERR| RESV4 | SType |  0x2  |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |  Possible Security Information
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |    RBridge-Channel (0x8946)   | CHV=0 |Nested Channel Protocol|
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |          Flags        |  ERR  |                               |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
>
> |         Nested Channel Protocol Specific Data ...             /
>
> /                                                               /
>
>