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

Magnus Westerlund <> Wed, 13 May 2015 11:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 809F81A0264; Wed, 13 May 2015 04:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ogp_5eE0FjDx; Wed, 13 May 2015 04:21:26 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63DF21A0263; Wed, 13 May 2015 04:21:25 -0700 (PDT)
X-AuditID: c1b4fb3a-f79ec6d000006dc0-05-555333b39777
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 46.BC.28096.3B333555; Wed, 13 May 2015 13:21:23 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 13 May 2015 13:21:22 +0200
Message-ID: <>
Date: Wed, 13 May 2015 13:21:21 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Alvaro Retana <>, The IESG <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvre5m4+BQg30tyhZ/f25ltLhw9zqT xYw/E5ktpi5/zOLA4jHl90ZWjyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoEr482ND8wFL2Qq Zry6ydzAuFC8i5GTQ0LAROLamw2MELaYxIV769m6GLk4hASOMkrM+rSEBcJZzigxe94upi5G Dg5eAW2JD/d8QRpYBFQlzi+ewwZiswlYSNz80QhmiwpESUz8eogFxOYVEJQ4OfMJmC0iYC/x c/87dhCbWSBVYveJX8wgtrBAusSPc5fBbCEBR4n1y5awgticAk4ST/cdZ4Got5CYOf88I4Qt L9G8dTZUvbZEQ1MH6wRGwVlI1s1C0jILScsCRuZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWb GIHBfHDLb6sdjAefOx5iFOBgVOLhVdgQFCrEmlhWXJl7iFGag0VJnNfO+FCIkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBsaipbqzl5WvLjG/+nuG8CfVvq5ZLXaOxVsuTRb5nNxeWdTr6uM6 K3br6iLNs0L2xyeKTV+5Zeq91wU7dhlOm33OWit1ZstL3dazHowu7v07v868tFpdm69qQ0RT T8G/z8/CZwgwy5mXBnvueOhmkays5Hsjoru1jferkaDKAa7UsJOLD97/9FaJpTgj0VCLuag4 EQCOZRgfRwIAAA==
Archived-At: <>
Cc:, "mmusic \(E-mail\)" <>
Subject: Re: [MMUSIC] Alvaro Retana's No Objection on draft-ietf-mmusic-rtsp-nat-evaluation-15: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 May 2015 11:21:28 -0000

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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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

This way, the term is known to the reader by the time they come to the 
summary in the end.


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: