Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-p2mp-bfd-08: (with COMMENT)

["Susan Hares" <[e-mail]>]

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:[e-mail]] 
Sent: Wednesday, January 24, 2018 1:40 PM
To: Zhangmingui (Martin)
Cc: The IESG; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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) <[e-mail]> 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:[e-mail]]
> Sent: Friday, January 19, 2018 1:49 AM
> To: The IESG
> Cc: [e-mail]; Susan Hares; [e-mail];
> [e-mail]; [e-mail]
> 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.
>