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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 18 Nov 2015 16:32:57 -0800

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?

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 19 Nov 2015 04:03:25 +0000

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:[email-masked]]
Sent: Wednesday, November 18, 2015 4:33 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Stephen Farrell's No Objection on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: (with COMMENT)

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

COMMENT:

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.

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.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Nov 2015 13:35:38 +0000

Hiya,

On 19/11/15 04:03, Gregory Mirsky wrote:
> 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:[email-masked]] Sent: Wednesday, November 18, 2015
> 4:33 PM To: The IESG Cc:
> [email-masked];
> [email-masked];
> [email-masked]; [email-masked]; [email-masked] Subject:
> Stephen Farrell's No Objection on
> draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: (with COMMENT)
> 
> 
> 
> 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
> 
> 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.

I wonder for how long though, that's now a five year old RFC.
Assuming it takes a few years for new deployments to pick up
new algorithms, isn't it time that a whole bunch of algorithm
choices were revisited?

> 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.

Pity that.

> GIM>> I think that we’ll need to make changes to RFC 5880 first
> (5880bis?). 

I don't see any reason why that is true. This document can easily
say "you MUST NOT use the horribly weak option specified in that
old RFC" with changing that old RFC.

> Besides, there’s RFC 7487 that describes RSVP-TE
> extensions to configure MPLS-TP OAM.

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

I did not ask if you should specify something here. I asked what
exists that is usable? If the answer is "nothing" then the text
in the draft would be misleading wouldn't it?

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

You're mis-interpreting me, I guess because my question wasn't
clear. My question above was a simple request for some background
information about the consequences of this architecture, and was
not a direct criticism of or comment on this draft. (Now if it
turns out there is no background material on the consequences of
this architecture, then that would be very interesting.)

Cheers,
S.

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 19 Nov 2015 14:44:44 +0000

Hi Stephen,
thank you for the clarifications. More in-line answers now tagged GIM2>>.

	Regards,
		Greg

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, November 19, 2015 5:36 AM
To: Gregory Mirsky; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's No Objection on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: (with COMMENT)

Hiya,

On 19/11/15 04:03, Gregory Mirsky wrote:
> 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
> 
> 
> 

I wonder for how long though, that's now a five year old RFC.
Assuming it takes a few years for new deployments to pick up new algorithms, isn't it time that a whole bunch of algorithm choices were revisited?

Pity that.

> GIM>> I think that we’ll need to make changes to RFC 5880 first

I don't see any reason why that is true. This document can easily say "you MUST NOT use the horribly weak option specified in that old RFC" with changing that old RFC.

GIM2>> Would adding the following in Section 2.2.4 BFD Authentication sub-TLV to AuthType explanation address your concern:
Simple Password SHOULD NOT be used if other authentication types are available.

> Besides, there’s RFC 7487 that describes RSVP-TE extensions to 
> configure MPLS-TP OAM.

> its scope. Mechanisms used only assumed and not discussed at length in 
> the document.

I did not ask if you should specify something here. I asked what exists that is usable? If the answer is "nothing" then the text in the draft would be misleading wouldn't it?
GIM2>> PKI (Public Key Infrastructure)

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

You're mis-interpreting me, I guess because my question wasn't clear. My question above was a simple request for some background information about the consequences of this architecture, and was not a direct criticism of or comment on this draft. (Now if it turns out there is no background material on the consequences of this architecture, then that would be very interesting.)

GIM2>> I see now that I've misread the question. LSP Ping, being Request-Reply mechanism with elaborate status reporting, provides self-throttling and sufficient self-diagnostic. In the document we're not discussing what happens if and when Echo request with OAM configuration TLVs times-out because of no Echo reply received as that is implementation specific. At the same time, implementation experience suggests that all of MPLS-TP OAM configuration can be communicated in a single Echo request thus minimizing network impact.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Nov 2015 14:53:34 +0000

Hiya,

Coupla bits more below...

On 19/11/15 14:44, Gregory Mirsky wrote:
> Hi Stephen, thank you for the clarifications. More in-line answers
> now tagged GIM2>>.
> 
> Regards, Greg
> 
> [mailto:[email-masked]] Sent: Thursday, November 19, 2015
> 5:36 AM To: Gregory Mirsky; The IESG Cc:
> [email-masked]; [email-masked]; [email-masked] Subject: Re:
>> [mailto:[email-masked]] Sent: Wednesday, November 18,
>> 2015 4:33 PM To: The IESG Cc: 
>> 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://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam-
>>
>> 
conf/
>> 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:-)
>> 
> Assuming it takes a few years for new deployments to pick up new
> algorithms, isn't it time that a whole bunch of algorithm choices
> were revisited?
> 
>> Authentication<http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth
>>
>> 
-03>
> I don't see any reason why that is true. This document can easily say
> "you MUST NOT use the horribly weak option specified in that old RFC"
> with changing that old RFC.
> 
> GIM2>> Would adding the following in Section 2.2.4 BFD Authentication
> sub-TLV to AuthType explanation address your concern: Simple Password
> SHOULD NOT be used if other authentication types are available.

Yes, I think adding that (or similar) is a nice improvement. We may
as well try discourage what we know are the weakest options.

> exists that is usable? If the answer is "nothing" then the text in
> the draft would be misleading wouldn't it? GIM2>> PKI (Public Key
> Infrastructure)

Huh? Sure one could invent a way to use PKI to help here. But that's
be a new thing.

So if we're agreed that that would require invention, doesn't that
mean that there is no existing usable mechanism and hence that the
current text is misleading?

I'd say just strike the misleading sentence.

>> 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?
>> 
>>  section notes need to have sufficient security mechanism for LSP
>> Ping communication.
> 
> You're mis-interpreting me, I guess because my question wasn't clear.
> My question above was a simple request for some background
> information about the consequences of this architecture, and was not
> a direct criticism of or comment on this draft. (Now if it turns out
> there is no background material on the consequences of this
> architecture, then that would be very interesting.)
> 
> GIM2>> I see now that I've misread the question. LSP Ping, being
> Request-Reply mechanism with elaborate status reporting, provides
> self-throttling and sufficient self-diagnostic. In the document we're
> not discussing what happens if and when Echo request with OAM
> configuration TLVs times-out because of no Echo reply received as
> that is implementation specific. At the same time, implementation
> experience suggests that all of MPLS-TP OAM configuration can be
> communicated in a single Echo request thus minimizing network
> impact.

Sure - I do get that the MPLS WG has consensus on this approach and
that'd only be the case if you think it works well. What I'm not at
all sure about is whether or not anyone has figured out what happens
if one runs (or abuses) a network managed in such a manner. Hence my
asking for a pointer to somewhere that has that kind of analysis.
But if we don't have one, we don't have one. (And again, that's not
a comment on this document really, just me asking for some more
background info.)

Cheers,
S.

> Cheers, S.

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 19 Nov 2015 15:27:08 +0000

Hi Stephen,

many thanks for your consideration and patience. I've captured changes to the text we've discussed:

·         added to 2.2.4 “Simple Password SHOULD NOT be used if other authentication types are available.”

·         removed from section 6 “and is assumed to use an off-line mechanism or an established secure key-exchange protocol” just leaving it as “Thus the exchange of security parameters (such as keys) for use in securing OAM is outside the scope of this document.”

·         to your last question – I don’t have information about such analysis.

I have prepared the new version to address comments from you and Ben Campbell.

Regards,

        Greg

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Thursday, November 19, 2015 6:54 AM
To: Gregory Mirsky; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's No Objection on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: (with COMMENT)

Hiya,

On 19/11/15 14:44, Gregory Mirsky wrote:

> Hi Stephen, thank you for the clarifications. More in-line answers now

> tagged GIM2>>.

> [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Subject: Re:

>> [email-masked]<mailto:[email-masked]>;

>> [email-masked]<mailto:[email-masked]>;

>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Subject:

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

>> ---------------------------------------------------------------------

>> -

> algorithms, isn't it time that a whole bunch of algorithm choices were

> revisited?

>> Authentication<http://tools.ietf.org/html/draft-bhatia-bfd-crypto-aut

>> h

-03>

>> - 2.1.1, I'd recommend saying any password auth-type MUST NOT be used

>> - would that be possible?

> SHOULD NOT be used if other authentication types are available.

Yes, I think adding that (or similar) is a nice improvement. We may as well try discourage what we know are the weakest options.

> exists that is usable? If the answer is "nothing" then the text in the

> draft would be misleading wouldn't it? GIM2>> PKI (Public Key

> Infrastructure)

Huh? Sure one could invent a way to use PKI to help here. But that's be a new thing.

So if we're agreed that that would require invention, doesn't that mean that there is no existing usable mechanism and hence that the current text is misleading?

>> hard to grok. Do you have a pointer to something (not too

> My question above was a simple request for some background information

> about the consequences of this architecture, and was not a direct

> criticism of or comment on this draft. (Now if it turns out there is

> no background material on the consequences of this architecture, then

> that would be very interesting.)

> configuration TLVs times-out because of no Echo reply received as that

> is implementation specific. At the same time, implementation

> communicated in a single Echo request thus minimizing network impact.

Sure - I do get that the MPLS WG has consensus on this approach and that'd only be the case if you think it works well. What I'm not at all sure about is whether or not anyone has figured out what happens if one runs (or abuses) a network managed in such a manner. Hence my asking for a pointer to somewhere that has that kind of analysis.

But if we don't have one, we don't have one. (And again, that's not a comment on this document really, just me asking for some more background info.)

Cheers,

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Nov 2015 15:27:50 +0000

Thanks Gregory, we're all set so.
S.