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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 28 Dec 2014 15:03:52 -0000

Hello Sam, authors, all,

Did I miss some update of this document?
It's now 133 days since I first did my review, and the changes requested were
not huge.

I know we all run out of energy towards the end of publication process, but if
there is no-one in the WG concerned to take this the final few steps, then
perhaps the WG doesn't need to request publication.

Thanks,
Adrian

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 19 October 2014 21:31
> To: 'Sam Aldrin'
> Cc: [email-masked]'; 'mpls'
> Subject: RE: [mpls] AD review of draft-ietf-mpls-proxy-lsp-ping
> 
> Hi Sam,
> 
> > >> Do you really need the pre-RFC5378 disclaimer?
> > 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".
> 
> > >> 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
> > >>
> > %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/messages/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.
> 
> > >> 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?
> > %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.
> 
> 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

---

From: Sam Aldrin <[email-masked]>
Date: Sun, 28 Dec 2014 11:59:06 -0800

Hi Adrian,

I am sorry for not publishing a new version.
I will do it at the earliest.
Sorry again for the delay.

-sam
> On Dec 28, 2014, at 7:03 AM, Adrian Farrel <[email-masked]> wrote:
> 
> Hello Sam, authors, all,
>