Subject: [trill] Comments on draft-ietf-trill-p2mp-bfd-04

From: Donald Eastlake <[email-masked]>
Date: Thu, 4 May 2017 14:50:10 -0400

Hi,

I've reviewed this document and have one new technical comment, two
editorials, and I repeat with suggested text a technical comment I had in
my recent message supporting.

*Technical Comments*

1. The Security Considerations section has a minor problem in that it
refers to RFC 7978 for security. RFC 7978 tells you how to do
point-to-point authentication and encryption but for multi-destination
cases like p2mp it provides only authentication. And, I believe, the
multipoint BFD draft provides authentication so it is not really necessary
to do it at the extended RBridge Channel message level. I suggest replacing
the first two paragraphs of the Security Considerations section with the
following:

"Multipoint BFD provides its own authentication but does not provide
encryption (see Security Considerations in [I-D.ietf-bfd-multipoint]). As
specified in this document, the point-to-multipoint BFD payloads are
encapsulated in RBridge Channel messages which have been extended by
[RFC7978] to provide security. However, [RFC7978], while it provides both
authentication and encryption for point-to-point extended RBridge Channel
messages, provides only authentication for multipoint RBridge Channel
messages. Thus, there is little reason to use the [RFC7978] security
mechanisms at this time. However, it is expected that a future document
will provide for group keying; when that occurs, the use of RBridge Channel
security will also be able to provide encryption and may be desirable."

2. As mentioned in
https://www.ietf.org/mail-archive/web/trill/current/msg07746.html
the bootstrapping section (Section 3) could be read to imply that multi-hop
multi-point BFD sessions could be bootstrapped with adjacency but I think
that only works for one-hop BFD sessions. I suggest that the first sentence
of Section 3 be replaced by the following two sentences:

"The TRILL adjacency mechanism bootstraps the establishment of one-hop
TRILL BFD
sessions [RFC7177 <https://tools.ietf.org/html/rfc7177>]. Multi-hop
sessions are expected to be configured by the network manager."

*Editorial Comments*
Section 1
OLD

   [I-D.ietf-bfd-multipoint-active-tail
<https://tools.ietf.org/html/draft-ietf-trill-p2mp-bfd-04#ref-I-D.ietf-bfd-multipoint-active-tail>].
If the tail loses
   connectivity of the new RBridge Channel message from the

   head, the

NEW

   [I-D.ietf-bfd-multipoint-active-tail
<https://tools.ietf.org/html/draft-ietf-trill-p2mp-bfd-04#ref-I-D.ietf-bfd-multipoint-active-tail>].
If the tail loses
   connectivity as detected by not receiving the new RBridge

   Channel message from the head, the

Section 5
OLD

   addition to this combination, TRILL P2MP BFD that requires the tail

NEW

   addition to this combination, TRILL P2MP BFD requires that the tail

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

---

From: "Zhangmingui (Martin)" <[email-masked]>
Date: Fri, 5 May 2017 09:55:28 +0000

Hi Donald,

Appreciate your comments. We authors agree with you and an update version based on your comments will be submitted soon.

Thanks,
Mingui

From: trill [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Friday, May 05, 2017 2:50 AM
To: [email-masked]
Subject: [trill] Comments on draft-ietf-trill-p2mp-bfd-04

Hi,

I've reviewed this document and have one new technical comment, two editorials, and I repeat with suggested text a technical comment I had in my recent message supporting.

Technical Comments

1. The Security Considerations section has a minor problem in that it refers to RFC 7978 for security. RFC 7978 tells you how to do point-to-point authentication and encryption but for multi-destination cases like p2mp it provides only authentication. And, I believe, the multipoint BFD draft provides authentication so it is not really necessary to do it at the extended RBridge Channel message level. I suggest replacing the first two paragraphs of the Security Considerations section with the following:

"Multipoint BFD provides its own authentication but does not provide encryption (see Security Considerations in [I-D.ietf-bfd-multipoint]). As specified in this document, the point-to-multipoint BFD payloads are encapsulated in RBridge Channel messages which have been extended by [RFC7978] to provide security. However, [RFC7978], while it provides both authentication and encryption for point-to-point extended RBridge Channel messages, provides only authentication for multipoint RBridge Channel messages. Thus, there is little reason to use the [RFC7978] security mechanisms at this time. However, it is expected that a future document will provide for group keying; when that occurs, the use of RBridge Channel security will also be able to provide encryption and may be desirable."

2. As mentioned in
https://www.ietf.org/mail-archive/web/trill/current/msg07746.html
the bootstrapping section (Section 3) could be read to imply that multi-hop multi-point BFD sessions could be bootstrapped with adjacency but I think that only works for one-hop BFD sessions. I suggest that the first sentence of Section 3 be replaced by the following two sentences:

"The TRILL adjacency mechanism bootstraps the establishment of one-hop TRILL BFD
sessions [RFC7177<https://tools.ietf.org/html/rfc7177>]. Multi-hop sessions are expected to be configured by the network manager."

Editorial Comments
Section 1
OLD

   [I-D.ietf-bfd-multipoint-active-tail<https://tools.ietf.org/html/draft-ietf-trill-p2mp-bfd-04#ref-I-D.ietf-bfd-multipoint-active-tail>].  If the tail loses

   head, the
NEW

   [I-D.ietf-bfd-multipoint-active-tail<https://tools.ietf.org/html/draft-ietf-trill-p2mp-bfd-04#ref-I-D.ietf-bfd-multipoint-active-tail>].  If the tail loses

Section 5
OLD

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