Subject: [mpls] AD review of draft-ietf-mpls-proxy-lsp-ping

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 17 Aug 2014 19:22:02 +0100

Hello,

Thanks for this draft. It completes another piece of the puzzle.

I have done my normal AD review to respond to the publication request. I
didn't find any show-stoppers, but I have a number of minor issues and 
questions.

As is usual, you should feel free (you are actively encouraged!) to tell
me I am wrong or that a change does not need to be made. I await your 
response either through email or with a revised I-D.

Thanks for the work,
Adrian

===

Do you really need the pre-RFC5378 disclaimer?

---

Please check for acronym expansions. I see:

LSR

---

A little inconsistency in "a LSP" and "an LSP".

---

Section 2 would be enhanced by a figure. Something like...

                      R3--R5---egress1
                     /
                    /
   ingress---R1---R2--Proxy--R6---egress2
                     /    \
                    /      \
                   /        R7--R8---egress3
                  /           \
                R4             \
               /                R9--egress4
              /                  \
             /                    \
       initiator                   egress5

Together with some explanatory text.

---

In 3.2 you have 
   An MPLS
   proxy ping reply message MAY be sent with a Return Code of <tba>,
   "Proxy Ping not authorized".

Should read <TBA-7>

---

Looking back at 4379, it is not clear to me how a legacy implementation
listening on port 3503 will react to receiving the new message type for
a proxy message. The text is phrased in terms of the ability to parse an
echo request/reply, and clearly the new message is neither of these.

So do you believe this is covered by 4379 section 4.4
   1. General packet sanity is verified.  If the packet is not well-
      formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code
      set to "Malformed echo request received" and the Subcode to zero.
You could make a case for that, although it is inside a section that
implies that the message type has already been determined and 
immediately follows the text...
   An LSR X that receives an MPLS echo request then processes it as
   follows.
(Also compare with section 4.6).

Anyway, you should include text on backward compatibility.
1. The case just described
2. The case where a targetted proxy doesn't support LSP ping at all.

---

Section 3.2

   If not, it
   sets the Return Code set to "Malformed echo request received" or "TLV
   not understood" (as appropriate)

Delete "set"
Worry about "as appropriate" because it assumes that the reader will
make the right choice where you probably want to be more prescriptive.

---

Section 3.2

   If
   the Reply Mode of the message header is not 1(Do not reply), an MPLS
   proxy ping reply message SHOULD be sent as described below.  In the
   latter case, the misunderstood TLVs (only) are included in an Errored
   TLVs TLV.

"the latter case"?

---

3.2

   If not, it sets the Return Code set to
   "Malformed echo request received" and the Subcode set to zero.

Delete "set"

---

3.2.1 has some lower case "should". Probably worth checking the whole
document for consistent 2119 usage.

---

3.2.2.

   When the Proxy LSR is a transit or bud node, downstream maps
   corresponding to how the packet is transited can not be supplied
   unless an ingress interface for the MPLS Echo Request is specified,
   since this information is not available and since all valid output
   paths are of interest, the Proxy LSR should include DS/DDMAP(s) to
   describe the entire set of paths that the packet can be replicated,
   like in the case where an LSP ping is initiated at the Proxy LSR.

Is that two sentences with "...specified.  Since..."?

I'm not sure what purpose Section 4.1 serves. I don't like that you 
have created a second (normative?) description of the message format.

Couldn't you just say:

   The format of MPLS LSP Ping messages is defined in [RFC4379].  This
   document defines two new message types as follows:

      Type     Message
      ----     -------
      TBA-1    MPLS proxy ping request
               (Pending IANA assignment)

      TBA-2    MPLS proxy ping reply
               (Pending IANA assignment)

---

The security considerations say:

   If such a network also carries Internet traffic, or permits IP access
   from other administrations, MPLS proxy ping message SHOULD be
   discarded at those points.  This can be accomplished by filtering on
   source address or by filtering all MPLS ping messages on UDP port.

I think that the mechanisms you describe here would also prohibit normal
LSP ping from transiting the network boundary. This is probably what 
you intend, but I note that 4379 does not make this recommendation so
the filtering you suggest here for proxy ping would have an effect on
all LSP ping function and changes the behavior of 4379.

The way to handle this, I think, is to paint it red. That is, say that
this is an additional filter compared to the advice in 4379, but it is
a damn fine idea.

Alternatively, you need to step back slightly and call on the border
nodes to look into the message type field.

---

It seems that proxy ping messages would be relatively easy to spoof.
This, combined with the fact that the receipt of a proxy ping causes
the proxy to retain state and to issue echo requests to the network
looks like two DoS vectors for the price of one.

So, I think you need:
- discussion of authentication for proxy requests
- recommendation to rate limit receipt of proxy requests
- recommendation to discard "duplicate" proxy requests

---

I'm not quite sure about the initiator being allowed to instruct the
proxy about which source port it must use in an echo request.  

(Incidentally, Section 3.2 doesn't restate that this has to happen
although 3.2.4.1 does restate it).

What happens if the proxy request asks for a reserved port number to be
used? What if the port is already in use by the proxy for something 
else? Why does it matter which source port the proxy uses? Why does the
proxy need to be able to control that? Why can't the proxy select its
own source port?
                                        
---

Should the point from 3.2.4.2 be echoed in the Security Considerations?

   If any additional labels are
   pushed onto the stack, their TTLs are set to 255. This will ensure
   that the requestor will not have control over tunnels not relevant to
   the FEC being tested.