Re: [tram] Publication has been requested for draft-ietf-tram-stun-pmtud-07

[Marc Petit-Huguenin <[e-mail]>]

Hi Spencer,

I case you missed the announcement, I published a new version of draft-ietf-tram-stun-pmtud with the modifications described in this thread.

Thanks.

On 08/20/2018 10:31 AM, Spencer Dawkins at IETF wrote:
> Hi, Marc,
> 
> On Mon, Aug 20, 2018 at 11:08 AM Marc Petit-Huguenin <
> [e-mail]> wrote:
> 
>> Hi SPencer,
>>
>> Sorry for the delay on resolving that issue.  See below for my answer.
>>
>> On 05/15/2018 08:33 AM, Spencer Dawkins at IETF wrote:
>>> Hi, Marc,
>>>
>>> On Mon, May 14, 2018 at 6:50 PM, Marc Petit-Huguenin <
>>> [e-mail]> wrote:
>>>
>>
>> [...]
>>
>>>>
>>>>>
>>>>> If using authentication in
>>>>>
>>>>>   UDP-based protocols that want to use any of these mechanisms,
>>>>>    including the PMTUD-SUPPORTED attribute, to signal PMTUD
>> capabilities
>>>>>    MUST ensure that it cannot be used to launch an amplification
>> attack.
>>>>>    For example, using authentication can ensure this.
>>>>>
>>>>> is only one way to ensure prevention of amplification attacks, is there
>>>> any
>>>>> guidance or reference you could point to that would help implementers
>>>>> evaluate other approaches?
>>>>
>>>> It's a good question.  I have to think about that.
>>>>
>>>
>>> Thanks for the quick and thorough responses.
>>>
>>> I think I'm good on your responses for all my other questions. I'll let
>> the
>>> working group chew on this one, and let the chairs/shepherd let me know
>>> when to request Last Call.
>>>
>>
>> As far as I can tell, there is 3 major ways of preventing source IP
>> spoofing at this layer, but I was not able to find a unique reference that
>> points to an explanation to these.
>>
>> So the plan is to add, after some copy-editing with my co-editor, the
>> following text in replacement of the "For example, using authentication can
>> ensure this." sentence:
>>
>>
>> "  An amplification attack can be prevented using three different
>>    techniques:
>>
>>    o  Authentication, where the source of the packet and the destination
>>       share a secret.
>>
>>    o  3 way handshake with some form of unpredictable cookie.
>>
>>    o  Make sure that the total size of the traffic potentially generated
>>       is lower than the size of the request that generated it."
>>
>>
>> Would that resolve that issue?
>>
> 
> Yes, it would.
> 
> I was hoping there would be a good reference you can point to, but if
> there's not, this is helpful.
> 
> I might suggest that your first sentence be something like
> 
> "An amplification attack can be prevented using techniques such as:"
> 
> just in case a security reviewer happens to know of a fourth technique. But
> I'll let you and Gonzalo do the right thing, and I'll request Last Call for
> your next version.
> 
> Thanks for chasing this down!
> 
> Spencer
> 
> 
>> Thanks.
>>


> 


-- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug