Eric:
Is there something I missed here. The referenced document is RFC5880 section 6.7 starts out: <https://tools.ietf.org/html/rfc5880#section-6.7> 6.7. Authentication An optional Authentication Section MAY be present in the BFD Control packet. In its generic form, the purpose of the Authentication Section is to carry all necessary information, based on the authentication type in use, to allow the receiving system to determine the validity of the received packet. The exact mechanism depends on the authentication type in use, but in general the transmitting system will put information in the Authentication transmitting system will put information in the Authentication Section that vouches for the packet's validity, and the receiving system will examine the Authentication Section and either accept the packet for further processing or discard it. The section 6.7 describes four types of authentication: simple password [6.7.2] , Keyed MD5 and Meticulous Keyed MD5 [6.7.3], Keyed SHA and Meticulous Key SHA1 authentication [6.7.4]. Do you wish TRILL to recommend a particular authentication for this draft if they use the BFD authentication? Please note that Kathleen noted this problem based on the sec-dir-review: https://mailarchive.ietf.org/arch/msg/secdir/KAZevWuVQAiukpRBKgjm7YIATRg Donald Eastlake’s response to the sec-dir review, and the changes in -08.txt are related to this issue. Donald points out that the RFC7978 provide strong authentication, and that we have a group keying mechanism ready for WG LC. If you have a moment, perhaps you can look at the group keying draft as well: https://datatracker.ietf.org/doc/draft-ietf-trill-group-keying/ It would be helpful to me as a WG chair to know if we have missed anything before we go into WG LC with this document in 2 days. Donald will be glad to answer additional questions on the group keying draft. Cheerily, Susan Hares From: Eric Rescorla [mailto:[email protected]] Sent: Wednesday, January 24, 2018 1:40 PM To: Zhangmingui (Martin) Cc: The IESG; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: Eric Rescorla's No Objection on draft-ietf-trill-p2mp-bfd-08: (with COMMENT) OK. This doesn't seem like it blocks this document, but I'll have to take a closer look when the referenced document comes up. On Mon, Jan 22, 2018 at 1:40 AM, Zhangmingui (Martin) <[email protected]> wrote: Hi Eric, Thanks for your review. When the referred document mentions Section 6.7, it actually points to the Section 6.7 of RFC5880. Thanks, Mingui > -----Original Message----- > From: Eric Rescorla [mailto:[email protected]] > Sent: Friday, January 19, 2018 1:49 AM > To: The IESG > Cc: [email protected]; Susan Hares; [email protected]; > [email protected]; [email protected] > Subject: Eric Rescorla's No Objection on draft-ietf-trill-p2mp-bfd-08: (with > COMMENT) > > Eric Rescorla has entered the following ballot position for > draft-ietf-trill-p2mp-bfd-08: 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-p2mp-bfd/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm hoping this can be resolved quickly, as it's probably just a missing > cite. If it > turns out that there's actually missing content, this may turn into a DISCUSS. > > 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 > > I skimmed the reference here, but wasn't able to figure out what the > authentication was. In particular, the document says: > > If the A bit is set, the packet MUST be authenticated under the > rules of section 6.7, based on the authentication type in use > (bfd.AuthType.) This may cause the packet to be discarded. > > But there is no 6.7. So, this makes me worry that I don't understand any of > this. >
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
