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

["Alvaro Retana (aretana)" <[e-mail]>]

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



>
>
>
>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.