Re: [mpls] MPLS-RT review of draft-bonica-mpls-self-ping

[Eric Gray <[e-mail]>]

Ron,

                I would be careful in using RFC 2119 language, to address only those
things that are externally visible.  There are not many in this draft, but a few
cases exist where use of SHOULD could tighten up the specification.

                I have a few comments as well.

                I noticed an ambiguity in the last bullet on page 4 (carried forward to
page 5):  I assume the intention is that optional use of a back-off algorithm
applies only to the timer expiry case (the current phrasing separates the step
of decrementing the retry from the optional additional step of increasing the
retry timer).  I suggest changing the last two sentences to read:

“Otherwise, decrement retries and, optionally, increase the value of retry-timer
  according to an appropriate back-off algorithm.”

                In section 3, it would be clearer why the bi-directional LSP case remains
distinct from bi-directional LSP Ping, if the word “independently” were added
between “LSP endpoint” and “tests LSP readiness” – however, there is still an
area of confusion that exists in this case: independent testing means readiness
is determined independently.

                This is fine if the only thing each LSP endpoint is trying to find out is if it
can forward packets using the LSP.  It is not as useful, if the status of the LSP is
dependent at either endpoint (e.g. – the initiator of the LSP setup) on the status
of the bidirectional LSP connectivity.

                This might be the case, for example, if a bi-directional LSP is used by an
implementation as an interface and the interface status depends on the ability
to use it in both directions.

                Should the draft say anything along these lines?

                The scenario in the Security Considerations section seems more than
usually contrived (i.e. – the vulnerability seems to be that of an attack that is
extremely feeble).

                The intent of the draft – as I understand it – is to ensure that traffic is
not switched onto an LSP that may not yet be functional as a result of a narrow
window of opportunity resulting from a race condition introduced by providing
a RESV message with label binding in parallel with the somewhat independent
installation of forwarding state information corresponding to the label binding.

                The window of opportunity for attack is then the time during which an
ingress LSR has received label binding information, and the time when each of
the LSRs on the LSP have actually installed corresponding forwarding state.  In
fact, the window is slightly narrower than that, given control and data plane
forwarding delays that allow slightly more time for forwarding state installation.

                During this time, an attacker needs to become aware that the ingress is
attempting to determine if the LSP is fully functional before transferring traffic
from some other path onto the LSP (it is possibly worth noting that – if there is
no other path, then there is little difference between forwarding them on a
possibly incomplete LSP or discarding them directly).

                As this window should be very narrow, the most likely scenario for this
to become a problem is if the attacker is a subverted LSR on the LSP, which may
then monitor LSP data traffic looking for this type of message, intercept it and
return it to the sending ingress LSR.

                If a transit LSR has been subverted, it is fairly obvious that this would be
the feeblest form of attack that the subversion might take, given that it could do
so many other things.

                If we really want to list this potential vulnerability, we should probably
say something about the associated (very low) risk, mitigating circumstances
and means of detection.

                Meanwhile, another form of attack might be if one or more LSRs in a
given MPLS domain were to start sending these self-ping messages at capacity
speeds.  Because they are at the data-plane, this attack vector might be harder
to detect at any affected egress LSR.  Meanwhile these messages consume at
least some of the network capacity across the network in both directions.

--
Eric

From: mpls [mailto:[e-mail]] On Behalf Of Ronald Bonica
Sent: Thursday, March 12, 2015 12:06 PM
To: [e-mail]; Gregory Mirsky; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls] MPLS-RT review of draft-bonica-mpls-self-ping



Works for me!

                   Ron


From: Adrian Farrel [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>
Sent: Thursday, March 12, 2015 11:01 AM
To: Ronald Bonica; 'Gregory Mirsky'; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: MPLS-RT review of draft-bonica-mpls-self-ping

Looks informational to me. And looks like 2119 language is appropriate.

Thanks,
Adrian

From: Ronald Bonica [mailto:[e-mail]]
Sent: 12 March 2015 01:24
To: Gregory Mirsky; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: MPLS-RT review of draft-bonica-mpls-self-ping

Greg,

In the message below, you question whether draft-bonica-mpls-self-ping should be INFORMATIONAL or PS. In a similar vein, you ask whether RFC 2119 language should be used.

When I wrote the draft, I considered both, couldn’t decide, and tossed a coin ;-)

AFAIKS, the IETFs criteria for PS are a bit fuzzy. You might argue that the draft should be PS because it defines “bits on the wire”. But on the other hand, you might argue that it doesn’t need to be PS because:


-          It doesn’t address interoperability requirements (because the sender and receiver are the same node)

-          It doesn’t request any IANA assignments

I would be very happy to let somebody else decide whether the draft should be INFORMATIONAL or PS. Maybe the chairs or ADs can offer an opinion?

                                                                                                   Ron



From: Gregory Mirsky [mailto:[e-mail]]
Sent: Monday, March 09, 2015 5:02 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: MPLS-RT review of draft-bonica-mpls-self-ping

Dear All,
I've been assigned to review draft-bonica-mpls-self-ping.
The document is very well written, the problem in focus is clearly stated, and the proposed solution well described.
I do have a number of concerns with the status of the document and the approach as presented:
•         document intended track is Informational even though the solution being positioned as "new, light-weight protocol". If this is indeed new protocol or even extension of the existing one, then I expect there must be requests to IANA allocations. At this time "This document makes no request of IANA." Either LSP Self-ping can be characterized through re-use of already existing protocols and approaches, or document should be switched to Standards track;