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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 12 Oct 2014 19:42:47 +0100

Hello,

How should I read the silence on this document?

Efficient spam filters?
Long summer vacations?
Lack of interest to continue?

Do the MPLS chairs need to appoint a new editor to complete the push?

Thanks,
Adrian

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 17 August 2014 19:22
> To: [email-masked]'
> Cc: [email-masked]
> Subject: AD review of draft-ietf-mpls-proxy-lsp-ping
> 
> 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.

---

From: Sam Aldrin <[email-masked]>
Date: Sun, 12 Oct 2014 11:55:24 -0700

Hi Adrian,

We did discuss amongst us and I should be able to get the new revision in couple of days. Silence is golden in this case and definitely not the other way :D. Seriously, apologize for not keeping you posted.

Sam

Sent from my iPhone

> On Oct 12, 2014, at 11:42 AM, Adrian Farrel <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 14 Oct 2014 23:36:44 -0700

Hi Adrian,

Have incorporated most of the changes related to your comments.
However, have couple of comments, which we need answers to, in order to make necessary changes.
See inline for my responses/questions.

Thanks
-sam

>> Do you really need the pre-RFC5378 disclaimer?
As this updates or add to RFC4379, we need that. Would you agree?
>> Please check for acronym expansions. I see:
%sam - Added terminology section.
>> 
>> ---
>> 
>> A little inconsistency in "a LSP" and "an LSP”.
%sam - done.
>> Together with some explanatory text.
%sam - We deliberated on this and feel it will add more confusion than helping the reader to understand. Also, it may necessitates lot of changes to the text to reflect the use of R1, R2 etc.
Would you be ok if we don’t add this ASCII art and keep it simple?
>>   "Proxy Ping not authorized".
%sam - Done. Updated in other places as well.
>> 2. The case where a targetted proxy doesn't support LSP ping at all.
%sam - Added few sub-sections to be more clear and also to define backward compatibility.
>> make the right choice where you probably want to be more prescriptive.
%sam - done.
>> "the latter case”?
%sam - reworded the text to remove the confusion.

>> Delete “set"
%sam - done
>> document for consistent 2119 usage.
%sam - Changed in all the places.
>> Is that two sentences with "...specified.  Since…"?
%sam - done.
>>   document defines two new message types as follows:
%sam - Kept only relevant text and removed the RFC4379 repeat.
>> nodes to look into the message type field.
%sam  - Adding the text.
>> - recommendation to discard "duplicate" proxy requests
%sam - Proxy do NOT maintain any state. Hence, not sure why the above apply to proxy and not regular Echo requests. When proxy echo request is, it (proxy LSR) merely issues a request and no state is maintained on it.
For ex: it has no way to discard duplicate requests, because is doesn’t maintain any state for the requests.
>> proxy need to be able to control that? Why can't the proxy select its
%sam - I think there is some confusion here. The source port number is not to request Proxy to use, rather to issue a request, so that the replying router could send the reply back to the initiator at the right port.
proxy echo request does not specify what port Proxy has to use.
>>   that the requestor will not have control over tunnels not relevant to
%sam - will add the text.

thanks
-sam

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 19 Oct 2014 21:30:50 +0100

Hi Sam,

> As this updates or add to RFC4379, we need that. Would you agree?

No, not really.
You can included it if you believe you are reproducing text that does not have a
transfer of copyright and for which it is hard to get the authors to confirm
copyright transfer. But the act of updating is not, itself, a reason to include
the disclaimer.

> >> Section 2 would be enhanced by a figure.
[snip]
> %sam - We deliberated on this and feel it will add more confusion than helping
> the reader to understand. Also, it may necessitates lot of changes to the text
to
> reflect the use of R1, R2 etc.
> Would you be ok if we don't add this ASCII art and keep it simple?

I won't object more than to say "I thought it would help".

> %sam - Proxy do NOT maintain any state. Hence, not sure why the above apply to
> proxy and not regular Echo requests. When proxy echo request is, it (proxy
LSR)
> merely issues a request and no state is maintained on it.
> For ex: it has no way to discard duplicate requests, because is doesn't
maintain
> any state for the requests.

I read in 3.2 (the description of processing at a Proxy)

   The header fields Sender's Handle and Sequence Number are not
   examined, but are saved to be included in the MPLS proxy ping reply
   or MPLS Echo Request messages.

Maybe that "saving" is ambiguous? Maybe this is an implementation specific note
for the message that is being built, and is not actually "state". If so, I think
you should strike "saved to be", s/message/message/ and add "...if one is sent
as a direct result of the received message."

Anyhow, the fact that a branch node will make copies of a ping to send
downstream *is* a vector.

> %sam - I think there is some confusion here. The source port number is not to
> request Proxy to use, rather to issue a request, so that the replying router
could
> send the reply back to the initiator at the right port.

Section 3.1 is about how to handle a received Proxy message

   The Reply mode and Global Flags of the Proxy Echo Parameters TLV are
   set to the values to be used in the MPLS Echo Request message header.
   The Source UDP Port is set to the value to be used in the MPLS Echo
   Request packet.  The TTL is set to the value to be used in the
   outgoing MPLS label stack.  See Section 5.1 for further details.

3.2.4.1 is describing how to build an echo request from a proxy request.

   The message is then encapsulated in a UDP packet.  The source UDP
   port is copied from the Proxy Echo Parameters TLV.  The destination
   port copied from the proxy ping request message.

And to be clear section 5.1 describes the Proxy Echo Parameters TLV

   The Proxy Echo Parameters TLV is a TLV that MUST be included in an
   MPLS proxy ping request message. 

I didn't go back and search the rest of the document.

If you do not intend that the proxy message can control the ports used in the
echo request, I think you have some text to fix. But surely this text is clear
and reflects the intention of the WG, in which case my questions hold.

Cheers,
Adrian