Re: [mpls] Stephen Farrell's No Objection on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: (with COMMENT)

[Gregory Mirsky <[e-mail]>]

Hi Stephen,

thank you for your review and comments. Please find my answers in-line and tagged GIM>>. Hope we can find good solution to address your concern with BFD security.



                Regards,

                                Greg



-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]]
Sent: Wednesday, November 18, 2015 4:33 PM
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Stephen Farrell's No Objection on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: (with COMMENT)



Stephen Farrell has entered the following ballot position for

draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: 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-mpls-lsp-ping-mpls-tp-oam-conf/







----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------





- 2.1.1, is there any chance of moving on from the "Keyed SHA1"

from RFC5880 to e.g. HMAC-SHA256 for this? We're generally trying to get that kind of transition done as we can and moving to use of a standard integrity check rather than a more home-grown one has some benefits. The HMAC-SHA1-like thing you're doing is still probably ok, (though could maybe do with crypto eyeballs on it as there may have been relevant new results since 2010) but future-proofing would suggest moving to HMAC-SHA256 if we can. (I can imagine such a change might require a new document, but am asking anyway:-)

GIM>> The fact is that we're bound by what is defined in RFC 5880. There was a proposal to strengthen BFD security BFD Generic Cryptographic Authentication<http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-03> but the document had expired.



- 2.1.1, I'd recommend saying any password auth-type MUST NOT be used - would that be possible?

GIM>> I think that we’ll need to make changes to RFC 5880 first (5880bis?). Besides, there’s RFC 7487 that describes RSVP-TE extensions to configure MPLS-TP OAM.



- section 6 - what "established secure key-exchange protocol"

is available to use here?

GIM>> The document considers key exchange mechanisms being outside its scope. Mechanisms used only assumed and not discussed at length in the document.



- (this is sort of off-topic) I find an architecture like this where a packet traversing a network has quite so many side-effects a bit hard to grok. Do you have a pointer to something (not too long:-) that explains the consequences of that?

GIM>> The first paragraph of the Security Considerations section refers to some scenarios that may suffice due to conditions (overload) in the management plane. The third paragraph of the same section notes need to have sufficient security mechanism for LSP Ping communication.