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

["Stephen Farrell" <[e-mail]>]

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:-)

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

- section 6 - what "established secure key-exchange protocol"
is available to use here?

- (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?