Re: [MMUSIC] Alvaro Retana's No Objection on draft-ietf-mmusic-rtsp-nat-evaluation-15: (with COMMENT)

[Magnus Westerlund <[e-mail]>]

Alvaro Retana (aretana) skrev den 2015-05-13 15:11:
> On 5/13/15, 7:21 AM, "Magnus Westerlund" <[e-mail]>
> wrote:
>
> Magnus:
>
> Hi!
>
>>>
>>>
>>>
>>> 2. Section 8 (Security Considerations) mentions the fact that "three way
>>> latching as well as ICE mitigates these security issues and performs the
>>> important return-routability check".  Please add a reference to this
>>> important check.  I looked at RFC5245 (ICE), but could not find that
>>> check described (just connectivity checks); is that what you're referring
>>> to with a different name?
>>>
>>
>> So the word return-routability check (really procedure) comes from
>> mobile IPv6. The point of these checks is that each side does perform a
>> check that I can send you a packet with a token, and you prove that you
>> received it by echoing it back. Thus, preventing off-path attacks. In
>> ICE this is done by the double sided connectivity checks.
>>
>> I suggest the following clarifications:
>>
>>
>> In Section 4.3.6:
>>     The ICE
>>     connectivity checks with their random transaction IDs from the server
>>     to the client servers as return-routability check and prevents off-
>>     path attacker to succeed with address spoofing.  Similar to Mobile
>>     IPV6's return routability procedure (Section 5.2.5 of [RFC3775]).
>
> For ICE, I would suggest pointing at RFC5245.  A small nit on the text
> (serves, not servers).
>
> NEW>
>    The ICE
>    connectivity checks [RFC5245] with their random transaction IDs from the
> server
>    to the client serves as return-routability check and prevents off-
>    path attacker to succeed with address spoofing.
> <NEW
>

Thanks,

I think that is unnecessary, as Section 4.3 is "ICE" and the earlier 
sub-sections contains the pointers to what ICE is.

/Magnus



>
>
>>
>>
>>
>> In Section 4.6.5
>>
>>     The client to server nonce and its echoing back does not protect
>>     against on-patch attacker, including malicious clients.  However, the
>>     server to client nonce and its echoing back prevents malicious
>>     clients to divert the media stream by spoofing the source address and
>>     port, as it can't echo back the nonce in these cases.  Similar to
>>     the Mobile IPv6 return routability procedure (Section 5.2.5 of
>>     [RFC3775])
>>
>> This way, the term is known to the reader by the time they come to the
>> summary in the end.
>
> Looks good.
>
> Thanks!
>
> Alvaro.
>
>
>


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------