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

From: Gregory Mirsky <[email-masked]>
Date: Mon, 9 Mar 2015 21:01:43 +0000

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;
•       s/back-holing/black-holing/
•       Section 2 LSP Self Ping Procedures states:
         The ingress LSR executes the following procedure until verification-
         status equals TRUE or retries is less than 1
      Is this recommendation MUST, SHOULD, MAY or an example of an implementation as illustration only? For the Informational document I expect it is the latter but need authors to clarify.
•       Use of two self ping sessions to validate bi-directional LSP may be acceptable in case of associated bi-directional LSP. In case of co-routed bi-directional LSP, which is usually egress signaled, such approach doesn’t seem practical.
•       Security implication of the proposed mechanism need more extensive discussion and methods to mitigate possible negative effects.
•       I would encourage compare the proposed Self Ping mechanism with S-BFD as LSP validation tool before the WG considers adoption of this proposal.

My conclusion:
      validation of the LSP is practical problem but I’m not certain that proposed mechanism is the best among others being discussed at IETF.

        Regards,
                Greg

-----Original Message-----
Subject: MPLS-RT review of draft-bonica-mpls-self-ping
Date: Tue, 24 Feb 2015 17:42:14 +0800
From: Loa Andersson <[email-masked]<mailto:[email-masked]>>
To: Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>, Gregory Mirsky <[email-masked]<mailto:[email-masked]>>, Mach Chen <[email-masked]<mailto:[email-masked]>>, Lizhong Jin <[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]>>, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>

Carlos, Greg, Mach and Lizhong,

You have be selected as MPLS-RT reviewers for draft-bonica-mpls-self- ping-04.

Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document.

Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound?  We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start).

Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs.

If you have technical comments you should try to be explicit about what
*really* need to be resolved before adopting it as a working group document, and what can wait until the document is a working group document and the working group has the revision control.

Are you able to review this draft by Mar 11, 2015? Please respond in a timely fashion.

Thanks, Loa
(as MPLS WG chair)
--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 11 Mar 2015 00:22:10 +0800

Hi authors,
I finish the MPLS-RT review for draft-bonica-mpls-self-04, and the document is clearly written.
The self-ping is useful in a normal network scenarios, and also will not work if uRPF is enabled on the egress. But there are more scenarios where self-ping will fail as below:
1. If one transite node wrongly installs a output lable as implicit null, then the self-ping reply message will be sent back by the next node. Then the ingress node will verify that the RSVP-TE LSP is OK, but the fact is the LSP is broken. That is self-ping could not detect the LSP down because of wrong label installation. 
2. In the network with link aggregation or other load balance mechanism, the self-ping may also provide wrong LSP validation information, but LSP Ping could support that scenario.
3. Reply message may not be able to route back to the ingress if the ingress IP address is not directly IP reachable for the egress node.
It is better to describe all fail scenarios in an independent section, like section 4. It should be highlighted to the reader.

For section 6, originally ingress could identify the LSP ping packet with well-known UDP port, and configure ACL rule to reduce risk of attack. But now it is more difficult to filter the packet with access list, which may increase the risk.

Overall, I have some concern with the tool of self-ping, especally to this fail scenarios. Let's assume ingress node receives the RESV message from downstream, then do self-ping, then:
1. if success, you are not ensured that the LSP is really OK.
2. if fail, you still have to use LSP Ping again.

Regards
Lizhong
 
From: Loa Andersson
Date: 2015-02-24 17:42
To: Carlos Pignataro (cpignata); Gregory Mirsky; Mach Chen; Lizhong Jin; [email-masked]; [email-masked]; <[email-masked]>
Subject: MPLS-RT review of draft-bonica-mpls-self-ping
Carlos, Greg, Mach and Lizhong,
 
You have be selected as MPLS-RT reviewers for draft-bonica-mpls-self-
ping-04.
 
Note to authors: You have been CC'd on this email so that you can know
that this review is going on. However, please do not review your own
document.
 
Reviews should comment on whether the document is coherent, is it
useful (ie, is it likely to be actually useful in operational
networks), and is the document technically sound?  We are interested
in knowing whether the document is ready to be considered for WG
adoption (ie, it doesn't have to be perfect at this point, but should be
a good start).
 
Reviews should be sent to the document authors, WG co-chairs and
WG secretary, and CC'd to the MPLS WG email list. If necessary, comments
may be sent privately to only the WG chairs.
 
If you have technical comments you should try to be explicit about what
*really* need to be resolved before adopting it as a working group
document, and what can wait until the document is a working group
document and the working group has the revision control.
 
Are you able to review this draft by Mar 11, 2015? Please respond in a
timely fashion.

Thanks, Loa
(as MPLS WG chair)
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 12 Mar 2015 01:23:53 +0000

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:[email-masked]]
Sent: Monday, March 09, 2015 5:02 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
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;

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 12 Mar 2015 02:33:18 +0000

Carlos, Lizhong,

In your reviews, you correctly assert that MPLS Self-Ping will fail if both of the following conditions are true:

-          uRPF is enabled interfaces that connect the ingress and egress LSRs to the network interior

-          Either the penultimate LSR pops the label or the egress LSR performs uRPF checking *after* removing the label

Fortunately, in networks where RSVP-TE is enabled, uRPF is rarely enabled on interfaces connecting to the network interior. This is because a traffic engineered LSP is likely to deliver a packet on an interface other than the one expected by uRPF.

I will note this in the next version of the draft.

                                                                               Ron

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 12 Mar 2015 02:41:06 +0000

Lizhong,

In your message review of draft-bonica-mpls-self-ping, you say:

“Reply message may not be able to route back to the ingress if the ingress IP address is not directly IP reachable for the egress node.”

This is most certainly true. The ingress node can prevent this problem by choosing the destination address carefully. For example, it the ingress node just signaled an LSP using RSVP-TE, it should use the same address in the MPLS Self-ping message that it used in the RSVP exchange.

                                                                               Ron

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 12 Mar 2015 02:50:28 +0000

Lizhong,

Implementation know the port(s) upon which they send MPLS Self-ping traffic. They can configure ACLs on that port or those ports. ACLs can protect dynamic ports, so long as they are predictable.

                                                                    Ron

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 12 Mar 2015 03:10:19 +0000

·         Security implication of the proposed mechanism need more extensive discussion and methods to mitigate possible negative effects.
Greg,

Good point, it the next rev of the draft, I will add text about configuring ACLs on the ingress LSR to protect against packets from unknown sources.

                                                                                                     Ron

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 12 Mar 2015 22:20:48 +0800

Lizhong,

[Lizhong] yes, it is possible to install ACL ruls everytime when MPLS self-ping is initiated. That is different with original implementation which is static ACL rule with well-know port. So it is better to describe how to reduce the risk of DoS if  MPLS self-ping is implemented.

Lizhong
 
                                                                    Ron

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 12 Mar 2015 15:00:33 -0000

Looks informational to me. And looks like 2119 language is appropriate.
 
Thanks,
Adrian
 
From: Ronald Bonica [mailto:[email-masked]] 
Sent: 12 March 2015 01:24
To: Gregory Mirsky; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: MPLS-RT review of draft-bonica-mpls-self-ping
 
Greg,

 

 
                                                                                                   Ron

 
Dear All,

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 12 Mar 2015 16:06:17 +0000

Works for me!

                   Ron

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

Thanks,
Adrian

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

Greg,

                                                                                                   Ron

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

Dear All,

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 12 Mar 2015 17:45:16 +0000

Hi Ron, et. al,
if authors consider changing characterization of Self Ping solution from “the new protocol” to perhaps “the new way to use elements of the MPLS LSP Ping protocol”, then Informational track indeed becomes inevitable.

                Regards,
                                Greg

From: Ronald Bonica [mailto:[email-masked]]
Sent: Thursday, March 12, 2015 9:06 AM
To: [email-masked]; Gregory Mirsky; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: MPLS-RT review of draft-bonica-mpls-self-ping

Works for me!

                   Ron

To: Ronald Bonica; 'Gregory Mirsky'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Thanks,
Adrian

Greg,

                                                                                                   Ron

Dear All,

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 12 Mar 2015 17:54:09 +0000

Adrian,

One additional nuance is that this document sends and unsolicited “Echo Reply” (i.e., not in response to an Echo Request), when RFC 4379 (PS) says:

https://tools.ietf.org/html/rfc4379#section-4.5 <https://tools.ietf.org/html/rfc4379#section-4.5>
4.5.  Sending an MPLS Echo Reply

   An MPLS echo reply is a UDP packet.  It MUST ONLY be sent in response
   to an MPLS echo request.  The source IP address is a routable address
   of the replier; the source port is the well-known UDP port for LSP
   ping.  The destination IP address and UDP port are copied from the
   source IP address and UDP port of the echo request.
...

Can an Informational doc change behavior of a PS?

Thanks,

Carlos.

> On Mar 12, 2015, at 8:00 AM, Adrian Farrel <[email-masked]> wrote:
> 
> From: Ronald Bonica [mailto:[email-masked] <mailto:[email-masked]>]
> To: Gregory Mirsky; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> From: Gregory Mirsky [mailto:[email-masked] <mailto:[email-masked]>]
> To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> _______________________________________________
> mpls mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 13 Mar 2015 00:34:07 +0000

Lizhong,

I think that we are misunderstanding each other’s words.

RFC 6335 divides UDP ports into the following ranges:

-          Well-known (0-1023)

-          User (1024-49151)

-          Dynamic (49152-65535)

The draft says that the UDP source and destination ports will be selected from the dynamic range. It *does not* say that UDP port numbers will be selected dynamically.

When writing the draft, I was assuming that a typical implementation selects a port form the dynamic range and sends all MPLS Self-ping traffic to that port. Therefore, the user could provision an ACL for that port.

I *was not* assuming that the application would select a different port each time that it ran MPLS-ping. This would make it very difficult to ACL MPLS Self-ping traffic.

If you like, I can make that assumption explicit in the draft.

                                                                 Ron

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 12, 2015 10:21 AM
To: Ronald Bonica; mpls-chairs; draft-bonica-mpls-self-ping; mpls-ads
Cc: mpls
Subject: RE: MPLS-RT review of draft-bonica-mpls-self-ping

Lizhong,

Lizhong

                                                                    Ron

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 13 Mar 2015 00:47:44 +0000

Greg,

I would be happy to strike the words “new protocol”. However, it might not be a good idea to replace those words with “a new way to use elements of LSP Ping”. If we were to do so, we might promote confusion regarding whether MPLS Self-ping extends LSP Ping.

Would you be OK if we replaced the words “new protocol” with “probing procedure”?

                                                                              Ron

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Thursday, March 12, 2015 1:45 PM
To: Ronald Bonica; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: MPLS-RT review of draft-bonica-mpls-self-ping

Hi Ron, et. al,

                Regards,
                                Greg

To: [email-masked]<mailto:[email-masked]>; Gregory Mirsky; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Works for me!

                   Ron

Thanks,
Adrian

Greg,

                                                                                                   Ron

Dear All,

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 13 Mar 2015 00:53:29 +0000

Hi Ron,
I agree with your proposal.

                Regards,
                                Greg

From: Ronald Bonica [mailto:[email-masked]]
Sent: Thursday, March 12, 2015 5:48 PM
To: Gregory Mirsky; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: MPLS-RT review of draft-bonica-mpls-self-ping

Greg,

                                                                              Ron

To: Ronald Bonica; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Ron, et. al,

                Regards,
                                Greg

Works for me!

                   Ron

Thanks,
Adrian

Greg,

                                                                                                   Ron

Dear All,

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 13 Mar 2015 01:56:54 +0000

Carlos,

You have a good point. Reusing the LSP Ping message format wasn’t the best idea in the world because it forces us to consider interactions with LSP Ping.

Could we solve the problem by defining a new message that is very similar to the LSP Ping message? The new message will contain only the following fields from the LSP Ping message:

-          Sender’s handle

-          Sequence Number

-          Timestamp sent (seconds)

-          Timestamp sent (microseconds)

All remaining fields from the LSP Ping message will be omitted.

                                                                                           Ron

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Thursday, March 12, 2015 1:54 PM
To: Adrian Farrel
Cc: Ronald Bonica; Gregory Mirsky; <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review of draft-bonica-mpls-self-ping

Adrian,

https://tools.ietf.org/html/rfc4379#section-4.5

Thanks,

Carlos.

On Mar 12, 2015, at 8:00 AM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Adrian

Greg,

                                                                                                   Ron

Dear All,

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Lizhong Jin" <[email-masked]>
Date: Fri, 13 Mar 2015 10:26:49 +0800

Ron,

Got it, thanks for the clarification. Yes, it is better to make it explicitly.

Regards

Lizhong

From: Ronald Bonica [mailto:[email-masked]] 
Sent: 2015年3月13日 8:34
To: [email-masked]; mpls-chairs; draft-bonica-mpls-self-ping; mpls-ads
Cc: mpls
Subject: RE: MPLS-RT review of draft-bonica-mpls-self-ping

Lizhong,

-          Well-known (0-1023)

-          User (1024-49151)

-          Dynamic (49152-65535)

                                                                 Ron

From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked]] 
Sent: Thursday, March 12, 2015 10:21 AM
To: Ronald Bonica; mpls-chairs; draft-bonica-mpls-self-ping; mpls-ads
Cc: mpls
Subject: RE: MPLS-RT review of draft-bonica-mpls-self-ping

Lizhong,

Lizhong

                                                                    Ron

---

From: Loa Andersson <[email-masked]>
Date: Fri, 13 Mar 2015 11:01:48 +0800

Ron,

The MPLS-RT review spawned some discussion on access lists. I could not
remember what you said about access lists in the draft so I checked. 
Quick search "access" and "ACL" and found that you do not mention
access lists at all. Maybe you should after the discussion here.

/Loa

On 2015-03-13 08:34, Ronald Bonica wrote:
> -Well-known (0-1023)
> -User (1024-49151)
> -Dynamic (49152-65535)
> The draft says that the UDP source and destination ports will be
> selected from the dynamic range. It **does not** say that UDP port
> numbers will be selected dynamically.
>
> When writing the draft, I was assuming that a typical implementation
> selects a port form the dynamic range and sends all MPLS Self-ping
> traffic to that port. Therefore, the user could provision an ACL for
> that port.
>
> I **was not** assuming that the application would select a different
> port each time that it ran MPLS-ping. This would make it very difficult
> to ACL MPLS Self-ping traffic.
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Thursday, March 12, 2015 10:21 AM
> *To:* Ronald Bonica; mpls-chairs; draft-bonica-mpls-self-ping; mpls-ads
> *Cc:* mpls
> *Subject:* RE: MPLS-RT review of draft-bonica-mpls-self-ping
>
>     For section 6, originally ingress could identify the LSP ping packet
>     with well-known UDP port, and configure ACL rule to reduce risk of
>     attack. But now it is more difficult to filter the packet with
>     access list, which may increase the risk.
>
>         Lizhong,
>
>         *//*
>
>         */Implementation know the port(s) upon which they send MPLS
>         Self-ping traffic. They can configure ACLs on that port or those
>         ports. ACLs can protect dynamic ports, so long as they are
>         predictable./*
>
>         [Lizhong] yes, it is possible to install ACL ruls everytime when
>         MPLS self-ping is initiated. That is different with original
>         implementation which is static ACL rule with well-know port. So
>         it is better to describe how to reduce the risk of DoS if MPLS
>         self-ping is implemented.
>
>         Lizhong
>
>         **
>
>         */
>         Ron/*
>
>         *//*
>
>
>
> [email-masked]

--

---

From: Loa Andersson <[email-masked]>
Date: Sat, 14 Mar 2015 12:03:37 +0800

Ron,

I would support a new message, I was never that found of sending
unsolicited Echo Reply message even if I saw no real reason not to.

You'll need a new message type, will you allocate that from the
LSP Ping registry, or create a registry of your own? And I'd like to
see the message format captured.

I also wonder if this brings the discussion about Informational/
Standards Track? DOn't you pass the border into creating a new
protocol if you do?

/Loa

On 2015-03-13 09:56, Ronald Bonica wrote:
> Carlos,
>
> You have a good point. Reusing the LSP Ping message format wasn’t the
> best idea in the world because it forces us to consider interactions
> with LSP Ping.
>
> Could we solve the problem by defining a new message that is very
> similar to the LSP Ping message? The new message will contain only the
> following fields from the LSP Ping message:
>
> -Sender’s handle
>
> -Sequence Number
>
> -Timestamp sent (seconds)
>
> -Timestamp sent (microseconds)
>
> *From:*Carlos Pignataro (cpignata) [mailto:[email-masked]]
> *Sent:* Thursday, March 12, 2015 1:54 PM
> *To:* Adrian Farrel
> *Cc:* Ronald Bonica; Gregory Mirsky; <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [mpls] MPLS-RT review of draft-bonica-mpls-self-ping
>
> Adrian,
>
> One additional nuance is that this document sends and unsolicited “Echo
> Reply” (i.e., not in response to an Echo Request), when RFC 4379 (PS) says:
>
>     *From:*Ronald Bonica [mailto:[email-masked]]
>     *Sent:*12 March 2015 01:24
>     *To:*Gregory Mirsky;[email-masked]
>     <mailto:[email-masked]>;[email-masked]
>     <mailto:[email-masked]>
>     *Cc:[email-masked]
>     <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>
>     *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.
>
>     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:[email-masked]]
>     *Sent:*Monday, March 09, 2015 5:02 PM
>     *To:[email-masked]
>     <mailto:[email-masked]>;[email-masked]
>     <mailto:[email-masked]>
>     *Cc:[email-masked]
>     <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>
>     *Subject:*RE: MPLS-RT review of draft-bonica-mpls-self-ping
>
>     Dear All,
>
>     The document is very well written, the problem in focus is clearly
>     stated, and the proposed solution well described.
>
>     ·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;
>

--

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 14 Mar 2015 04:49:47 +0000

Hi Ron,

I think that is a better approach. Thanks!

— Carlos.

> On Mar 12, 2015, at 6:56 PM, Ronald Bonica <[email-masked]> wrote:
> 
> Carlos,
> 
> From: Carlos Pignataro (cpignata) [mailto:[email-masked] <mailto:[email-masked]>]
> Cc: Ronald Bonica; Gregory Mirsky; <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On Mar 12, 2015, at 8:00 AM, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Eric Gray <[email-masked]>
Date: Mon, 16 Mar 2015 15:37:37 +0000

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:[email-masked]] On Behalf Of Ronald Bonica
Sent: Thursday, March 12, 2015 12:06 PM
To: [email-masked]; Gregory Mirsky; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review of draft-bonica-mpls-self-ping

Works for me!

                   Ron

From: Adrian Farrel [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

Thanks,
Adrian

Greg,

                                                                                                   Ron

Dear All,

---

From: Ron Bonica <[email-masked]>
Date: Tue, 17 Mar 2015 10:13:10 +0000

Ack.

I will catch this in the next draft version.

                              Ron

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Friday, March 13, 2015 4:02 AM
> To: Ronald Bonica; [email-masked]; mpls-chairs; draft-bonica-mpls-self-
> ping; mpls-ads
> Cc: mpls
> Quick search "access" and "ACL" and found that you do not mention access
> lists at all. Maybe you should after the discussion here.
> 
> /Loa
> 
> > I think that we are misunderstanding each other's words.
> >
> > port each time that it ran MPLS-ping. This would make it very
> > difficult to ACL MPLS Self-ping traffic.
> >