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

[Loa Andersson <[e-mail]>]

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]