Re: [mpls] Are we ready to post a version soon? - Re: AD review of draft-ietf-mpls-proxy-lsp-ping

[Sam Aldrin <[e-mail]>]

Hi Loa,

I am on a business trip for the past 2+ weeks. I plan to post an updated version in the coming week. Thanks for your understanding.

Cheers
Sam

Sent from my iPhone

> On Jan 22, 2015, at 6:57 PM, Loa Andersson <[e-mail]> wrote:
> 
> Folks,
> 
> Counter says 158 days can we post a new version soon??
> 
> /Loa
> 
>> On 2014-12-29 03:59, Sam Aldrin wrote:
>> 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 <[e-mail]> wrote:
>>> 
>>> 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:[e-mail]]
>>>> Sent: 19 October 2014 21:31
>>>> To: 'Sam Aldrin'
>>>> Cc: '[e-mail]'; '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
> 
> -- 
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]