Re: [trill] [secdir] Secdir last call review of draft-ietf-trill-p2mp-bfd-07
Hiya, On 29/12/17 23:37, Donald Eastlake wrote: > OLD >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. > > NEW >[RFC7978] provides encryption only for point-to-point extended >RBridge Channel messages so its encryption facilities are not >applicable to this draft. However [RFC7978] provides stronger >authentication than that currently provided in BFD. Thus, there is >little reason to use the BFD security mechanisms if [RFC7978] >authentication is in use. It is expected that a future TRILL >document will provide for group keying; when that occurs, the use >of [RFC7978] RBridge Channel security will be able to provide both >encryption and authentication. Were that change acceptable to the WG, I'd be supportive, and it'd clearly solve what I thought was an issue with the current spec. Cheers, S. -- PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) 0x7B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
[trill] Secdir last call review of draft-ietf-trill-p2mp-bfd-07
Reviewer: Stephen Farrell Review result: Has Issues Mostly this draft is just bookkeeping so BFD can use trill's P2MP capabilities. I think there is one issue to consider, though since I've not read all the referenced documents in detail, I'm open to correction as to whether or not this is a real issue. IIRC, BFD has some pretty crappy "authentication" schemes, such as allowing a cleartext password, and not using HMAC when doing keyed hashes. That's been justified by performance and implementation requirements for BFD. (Not that I ever found those justifications that satisfactory myself:-) I don't think TRILL has the same issues in that (again IIRC) TRILL doesn't define such "dodgy" schemes, so that leads me to wonder if this text is really correct/wise: "...there is little reason to use the [RFC7978] security mechanisms at this time..." I'd have thought that avoiding the more-dodgy BFD mechanisms would be a reason for using TRILL authentication mechanisms. In addition, it's not clear (to me) from the draft if the security assumptions made for BFD still hold in the environments where TRILL is likely to be used. If not, then that'd be another reason to argue that TRILL authentication ought be used. ___ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
[trill] Stephen Farrell's No Objection on draft-ietf-trill-rfc6439bis-04: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-trill-rfc6439bis-04: 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-rfc6439bis/ -- COMMENT: -- - section 6: is port-shutdown a new potential DoS vector? Shouldn't that be noted here and/or in section 9? ___ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
[trill] Stephen Farrell's No Objection on draft-ietf-trill-arp-optimization-06: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-trill-arp-optimization-06: 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-arp-optimization/ -- COMMENT: -- 3.2, 2nd last para: don't you need to say to never fake SEND responses? saying "prevent local reply" seems unclear to me, and a MUST NOT would seem called for. I guess Suresh's discuss covers that though, so just to note I agree with him on that. ___ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
