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

[Magnus Westerlund <[e-mail]>]

Thanks for the review!


Alvaro Retana skrev den 2015-05-12 23:30:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-mmusic-rtsp-nat-evaluation-15: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I have two comments:
>
> 1. The introduction states that multiple levels of NATs (including CGNs)
> were  not considered.  While I understand the history behind this draft
> and the time frame when it was written, I would really like to see
> something mentioned about the potential impact on the different
> techniques.  (I could only find a brief discussion in section 4.4
> (Latching) to the potential effect of multiple NATs/CGN.  Something
> similar to the text there would be ideal.)

I agree that it would be preferable to have significant considerations 
for multi-level NATs, but we really have no cycles to spend on this.

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



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.

Cheers

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