Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02

From: Erik Nordmark <[email-masked]>
Date: Wed, 01 Feb 2012 11:44:54 -0800

The WG last call ends on Feb 15th.
Please send comments (including ones that say you've read the document 
and it is fine) to the rbridge list.

   Erik
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 14 Feb 2012 23:42:22 -0500

I would like to suggest the addition of some material to the Security
Considerations section. Something like what I've pasted below my .sig
and above Erik's message blow...

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

   Consist with TRILL's goal of minimum configuration, the default for
   BFD security between neighbor RBridges is based on that state of
   IS-IS shared secret authentication for Hello between those
   RBridges.  If such IS-IS authentication is not in effect then, by
   default, TRILL BFD between those RBridges is also unsecured. But
   the RBridges may be configured to use BFD Security.

   If such IS-IS authentication is in effect then, unless configured
   otherwise, TRILL BFD Control frames sent between those RBridges use
   BFD Meticulous Keyed SHA1 authentication [RF5880] with keying
   material derived as shown below

       HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC |
                        originatorPortID ), IS-IS-shared-key )

   where HMAC-SHA256 [RFC6234], "TRILL BFD Control" is the seventeen
   byte US ASCII [RFC20] string indicated that is then concatenated
   with the 6-byte MAC of the originating port and then the 2-byte
   Port ID as would be sent in a TRILL Hello on that port. These
   quantities are included to minimize expose of the same key to
   improve resistance to cryptanalysis. IS-IS-key is the secret keying
   material being used for IS-IS authentication on the link. In the
   Authentication Section of the BFD Control frame OAM protocol
   specific data, Auth Type would be 5, Auth Len would be 28, and Auth
   Key ID is zero. The RBridges MAY be configured to use other BFD
   security modes or keying material including configuration to use no
   security.

   Authentication for TRILL BFD Echo SHOULD be provided but is a local
   implementation issue as BFD Echo frames are authenticated by their
   sender when received in the form of Echo responses. However, if
   TRILL IS-IS and BFD Control are being authenticated to a neighbor
   and BFD Echo is in use, BFD Echo frames to be returned by that
   neighbor SHOULD be authenticated and such authenticate SHOULD use
   different keying material from other types of authentication.  For
   example, it could use keying material derived as follows:

      HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC |
                      originatorPortID ), IS-IS-shared-key )

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 15 Feb 2012 11:18:13 -0500

Editorial Comments on draft-ietf-trill-rbridge-bfd-02.txt

In the body of the text, the RBridge Channel draft is sometimes
   references as "[TRILLChannel]" and sometimes as "[TRILLoam]". Since
   TRILLChannel seems clearer and is how it actually appears in the
   Normative References section, suggest globally replacing "TRILLoam"
   with "TRILLChannel".

In Section 12, it would be clearer if "range" was replaced by "range
   of RBridge Channel protocol numbers".

In the References, I believe RFCs 5082 and 5586 should be moved from
   Normative to Informational.

Typos:
      "plaen" -> "plane"

Thanks,
Donald

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 15 Feb 2012 15:14:37 -0800

I've read the latest version of the draft and looks fine. Have no further comments.

Cheers
Sam

Sent from my iPad

---

From: ayabaner <[email-masked]>
Date: Wed, 15 Feb 2012 21:27:54 -0800

Donald,

Some comments in-line.

Thanks,
Ayan

> and above Erik's message blow...

[Ayan] I am assuming that the configuration above for the BFD Security is
independent on the IS-IS authentication configurations (if any).

>    material being used for IS-IS authentication on the link.

[Ayan] Should we be sharing the "secret" key between the two protocols or
mandate the user to configure both to be identical. I realize the minimal
configuration goals, but I am wondering if it would be nice to keep the core
TRILL-BFD pieces TRILL-IS-IS agnostic.

>    In the

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 16 Feb 2012 22:37:12 -0500

Hi Ayan,

> independent on the IS-IS authentication configurations (if any).

Yes. The idea is just that, in the normal case where if you are going
to secure one, you are probably going to secure both Hellos and BFD,
consistent with TRILL's goal of minimal required configuration, you
should only have to configure IS-IS security if you are willing to
take the default BFD security.

> TRILL-BFD pieces TRILL-IS-IS agnostic.

This text doesn't go into implementation details, and I don't think it
should, you just need some way to give the key to the BFD code. Since
the BFD is derived in a cryptographically secure way from the IS-IS
key, neither one reveals anything about the other. Actually, the
expression for the key could be simplified. Since the PortID isn't
actually in the BFD messages, including it causes some complications
so it should probably be removed...

Improved text, including typo fixes, at bottom of message below.

Thanks,
Donald

>>> and it is fine) to the rbridge list.

   Consistent with TRILL's goal of being able to operate with minimum
   configuration, the default for BFD security between neighbor
   RBridges is based on that state of IS-IS shared secret
   authentication for Hello between those RBridges. However, if such
   BFD security is configured then its configuration is independent of
   that for IS-IS security.

   If IS-IS authentication is not in effect between neighbor RBridges
   then, by default, TRILL BFD between those RBridges is also
   unsecured. If such IS-IS authentication is in effect then, unless
   configured otherwise, TRILL BFD Control frames sent between those
   RBridges use BFD Meticulous Keyed SHA1 authentication [RF5880] with
   keying material derived as shown below

       HMAC-SHA256 ( ( "TRILL BFD Control" | originatorMAC ),
                     IS-IS-shared-key )

   where HMAC-SHA256 is described in [RFC6234], "TRILL BFD Control" is
   the seventeen byte US ASCII [RFC20] string indicated that is then
   concatenated with the 6-byte MAC of the originating port. The MAC
   is included to minimize exposure of the same key to improve
   resistance to cryptanalysis. IS-IS-key is the secret keying
   material being used for IS-IS authentication on the link. In the
   Authentication Section of the BFD Control frame OAM protocol
   specific data, Auth Type would be 5, Auth Len would be 28, and Auth
   Key ID is zero. The RBridges MAY be configured to use other BFD
   security modes or keying material or configured to use no security.

   Authentication for TRILL BFD Echo is a local implementation issue
   as BFD Echo frames are authenticated by their sender when received
   in the form of Echo responses. However, if TRILL IS-IS and BFD
   Control are being authenticated to a neighbor and BFD Echo is in
   use, BFD Echo frames to be returned by that neighbor SHOULD be
   authenticated and such authenticate SHOULD use different keying
   material from other types of authentication.  For example, it could
   use keying material derived as follows:

      HMAC-SHA256 ( ( "TRILL BFD Echo" | originatorMAC ),
                    IS-IS-shared-key )

---

From: Radia Perlman <[email-masked]>
Date: Thu, 16 Feb 2012 21:58:01 -0800

I've read it and it seems fine.

Radia

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 17 Feb 2012 08:30:27 +0000

I've read it. It looks fine.

Mingui

   > -----Original Message-----
   > From: [email-masked] [mailto:[email-masked]] On
   > Behalf Of Erik Nordmark
   > Sent: Thursday, February 02, 2012 3:45 AM
   > To: [email-masked]
   > Subject: [rbridge] WG last call on draft-ietf-trill-rbridge-bfd-02
   > 
   >

---

From: Jon Hudson <[email-masked]>
Date: Sat, 18 Feb 2012 00:48:42 -0800

I have read and support this.

it's especially nice to see security being discussed. This is becoming more
and more a frequent conversation point when talking TRILL with certain
customers.

....the same customers that keep me offline for 2 days :-/

-- 
"Do not lie. And do not do what you hate."
"Don't worry, be happy"
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Thomas Narten <[email-masked]>
Date: Thu, 23 Feb 2012 20:21:18 -0500

Overall, I support this document. It does need a respin to clean up
what appear to be straightforward editing issues.

Thomas

Document probably should have a reference to core BFD RFCs earlier in
the document than it does (e.g., first use).

   there is work in the area.  The Rbridge Channel facility is specified
   in [TRILLoam].

s/TRILLoam/CHANNELoam/ 

   it and TRILL data plaen layer OAM, such as TRILL BFD, is beyond the

s/plaen/plane/

   TRILL BFD Control frames are unicast TRILL Rbridge Message Channel
   frames [TRILLChannel].  The Rbridge Channel Protocol value is given
   in Section 10.

There is no such term as "TRILL Rbridge Message Channel frames". I
think you want to just say "Trill Rbridge Channel frames" (i.e., drop
"Message"). Multiple occurances throughout document.

   A TRILL BFD Echo frame is a unicast TRILL OAM Message Channel
   frame,

Drop "OAM"? Indeed, the entire document needs a pass to remove
references to "OAM" that are no longer valid. BFD is now just part of
the channel draft.   

   A TRILL BFD Echo frame is a unicast TRILL OAM Message Channel frame,
   as specified in [TRILLoam], which should be forwarded back by an

Drop "OAM" from above. Also, drop "Message", as that isn't the proper
term (I think).   

Better:

   A TRILL BFD Echo frame is a unicast TRILL Channel frame as
   specified in [TRILLoam] with a Channel Protocol value of "BFD
   Echo". Such packets should be forwarded back ...

Need a reference in references section to TRILLoam document

   TRILL BFD Echo frames SHOULD only be sent on a link if

   A TRILL BFD Control session has been established,

Format problem above. Truncated sentence?  

   TRILL BFD Echo support is indicated by the potentially echo
   responding RBridge.

This sentence reads awkward.

   The adjacency is in the Report state [RFC6327], and

Truncated sentence again?

   It is required that the operator of an RBridge campus configure the
   rates at which TRILL BFD frames are transmitted on a link to avoid
   congestion (e.g., link, I/O, CPU) and false failure detection.

Don't like the "required" wording.   Better to say something like "it
is up to the operator to ..."

   IANA is request to allocate two TRILL OAM Protocol numbers from the
   range allocated by Standards Actions, as follows:

Change wording of "OAM Protocol numbers"?

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 24 Feb 2012 12:02:11 -0500

Hi Thomas,

Thanks for your corrections below. Some of these were previously
posted to the list or communicated to Vishwas Manral who is the
current editor of the document. Vishwas has been asked to spin a new
version.

On the "sentence fragments" you mention, I believe that is supposed to
be a bulleted list and should be indented with bullets.

On the last comment in your message, concerning the use of "required",
that word was copied from RFC 5881 but I think your suggested change
is fine.

Thanks again,
Donald

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 24 Feb 2012 15:15:37 -0800

The WG last call on the bfd draft shows overall support for advancing 
this document to the IESG. Some editorial suggestions have been made, 
and it makes sense to apply those and produce an updated draft before we 
forward the document to the IESG.

Thanks for the reviews,
    Erik and Donald

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 24 Feb 2012 15:06:56 -0800

> and above Erik's message blow...

A few editorial nits and an editorial question below.

>     Consist with TRILL's goal of minimum configuration, the default for

s/Consist/Consistent/

>     Port ID as would be sent in a TRILL Hello on that port.

Do we need to specify the byte order for the originatorMAC and 
originatorPortID to make sure that the sender and receiver use the same 
byte order when deriving the key?

> These

Should it be "exposure" instead of "expose"?

>     improve resistance to cryptanalysis. IS-IS-key is the secret keying

s/IS-IS-key/IS-IS-shared-key/

    Erik

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 24 Feb 2012 15:18:34 -0800

Yes, I will edit the draft over the weekend.

-Vishwas

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 24 Feb 2012 21:14:01 -0500

Hi Erik,

A later improved version is here
http://www.postel.org/pipermail/rbridge/2012-February/004768.html

It should probably specify "network byte order".

Thanks,
Donald

On Fri, Feb 24, 2012 at 6:06 PM, Erik Nordmark <[email-masked]> wrote:
> originatorPortID to make sure that the sender and receiver use the same byte
> order when deriving the key?
>
>
>> These

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 25 Feb 2012 17:08:07 -0800

Hi Donald,

I started to edit the document. I agree with the general concept of what we
are trying to achieve but I disagree with the changes you mention below.

I think BFD security should be in the BFD spec (infact there is BFD WG work
on the same ). We can talk about keys used in the BFD. We already have work
on the algorithms of BFD located in the link below. I do not see a reason
BFD should use Keying mechanisms any different from what base BFD
specification provides. Guess a reference to the below draft could be good
enough.

http://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-00

I have attached the documents with the changes discussed in the WG though.

Thanks,
Vishwas

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 27 Feb 2012 13:11:28 -0500

Hi Vishwas,

See separate response to be posted later on the Security
Considerations material.

On editorial changes:
1. I don't know why "Channel" was deleted in the first entry in
Section 2. It is usual in acronym explanations to show what each
letter stands for and it was my impression that the middle letter in
ACH stood for Channel.
2. The two occurrences of "[TRILLoam]" need to be changed to "[TRILLChannel]".
3. The references to RFC 5082 and RFC 5586 should be moved from the
lists of Normative References to Informative References.
4. Replace "plaen" with "plane".
5. After the first paragraph in Section 9, there is an introductory
line followed by 4 points. (5a) The second point ends with a period
and, to be consistent, should end in a comma. (5b) The 4 points should
each be at least indented and probably bulleted (that is, each point
started with "o  " (a lower case oh followed by two spaces) or
something like that.
6. In Section 10, replace "It is required that the operator of an
RBridge campus configure ..." with "It is up to the operator of an
RBridge campus to configure ...".

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 28 Feb 2012 23:56:00 -0500

Hi Vishwas,

On Sat, Feb 25, 2012 at 8:08 PM, Vishwas Manral <[email-masked]> wrote:
> on the same ). We can talk about keys used in the BFD.

I agree with that. Perhaps there are a few missing words in the text I
proposed. My goal was just to say that, if a bunch of conditions are
met as stated, then the default algorithm ("authentication type" in
BFD terminology) and keying material are as the proposed text states.
The base BFD RFC 5880 says

   The same authentication type, and any keys or other necessary
   information, obviously must be in use by the two systems.  The
   negotiation of authentication type, key exchange, etc., are all
   outside the scope of this specification and are expected to be
   performed by means outside of the protocol.

So, specifying a default authentication type (Meticulous Keyed SHA1)
and default keying material, the this TRILL BFD draft is specifying
something which is explicitly outside the scope of the BFD protocol.

> We already have work
> on the algorithms of BFD located in the link below.

In RFC 5880, I believe the algorithms you are talking about are called
"authentication type". The TRILL BFD draft does not add any new
authentication type.

> I do not see a reason
> specification provides.

As far as I can see, the base BFD specification provides no mechanism
for getting the same keying material at the communicating stations.

> Guess a reference to the below draft could be good enough.

I don't see what the above draft has to do with it as that draft
simply specifies addition authentication types.

Perhaps some aspects of the text are unclear. As editorial
clarifications, I would suggest the following changes:
(1) replace the three occurrences of "BFD security" with "BFD authentication".
(2) as suggested by Erik Nordmark, replace "...  the 6-byte MAC of the
originating port." with "... the 6-byte MAC of the originating port in
network byte order."
(3) Inserting a new sentence just after "... used for IS-IS
authentication on the link." as follows "This is accomplished by
associating the above default authentication type and key with Key ID
zero and using that Key ID." This is, to my mind, already implied when
it later says the Key ID field is zero, but I think adding this
sentence makes it clearer.

> I have attached the documents with the changes discussed in the WG though.

See http://www.postel.org/pipermail/rbridge/2012-February/004818.html

Thanks,
Donald