Subject: [MMUSIC] ICE issue: obfuscating candidate addresses

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Dec 2004 23:32:27 -0500

In ICE-03, the IP addresses in the a=candidate attribute are "in the 
clear". If the SDP is not protected (for example using SIP over TLS or 
S/MIME), a "helpful" NAT which sees the SDP may try to rewrite the IP 
addresses it sees in the payload. The STUN revision 
(draft-ietf-behave-rfc3489bis) addressed this by including an obfuscated 
version of the address in the STUN response, so these "helpful" nats 
couldn't rewrite them.

I got a private comment suggesting that we do the same for ICE, to 
prevent the same problem. Its less severe here, since SIP over TLS will 
eliminate the problem (you can't run STUN BindingRequests over TCP). 
However, for UDP it is a similar problem.

So, the proposal would be to encode the IP address/port in the SDP by 
xor'ing it with the lower bits of the username field.

The pros/cons of this approach are:

PROS

   - avoids incorrect ICE operation when "helpful" nats try to rewrite 
IP addresses they see in packets

CONS

   - debugging harder since IP/port are not directly readable
   - result of xor needs to be base64 encoded (or something similar) 
since the xor operation may not produce valid SDP characters
   - slightly larger SDP messages due to base64 encoding

I'm somewhat on the fence here since the right answer is really "use 
TLS". The costs are relatively low, but this type of NAT is not that 
common, so the risk is low as well. I'm probably inclined to not make 
the change, and just document the issue.

Comments?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 08 Dec 2004 11:07:29 -0500

I'm on the fence too, but UDP without S/MIME is out there, and if the 
problem warrants a solution in STUN, it begs the question of why it 
wouldn't warrant a similar solution here. I'm open either way.

-- Flemming

Jonathan Rosenberg wrote:

> (draft-ietf-behave-rfc3489bis) addressed this by including an 
> obfuscated version of the address in the STUN response, so these 
> "helpful" nats couldn't rewrite them.
>
> prevent the same problem. Its less severe here, since SIP over TLS 
> will eliminate the problem (you can't run STUN BindingRequests over 
> TCP). However, for UDP it is a similar problem.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 08 Dec 2004 17:58:45 +0100

Hi Jonathan,

A few questions:

- Are these NATs that are helpfull common?

- How can these helpful NATs work at all. Even if I only replace bytes 
that matches the private source IP address of an outgoing packet. There 
must be significant risk that the packet contains that pattern in 
something that is not and adress. Do they only do this is certain 
identfiable protcols?

- Finnally if they only replace addresses related to the private 
adresses, would an replacement actually have any ill-effect on ICE? It 
would foul up the default address, however with a explicit syntax, only 
the default and binding adress woudl be replaced, not the candidate? 
Unless the candidate is the private source adress, which anyway becomes 
unvalid by the passing through the NAT.

So please consider a bit more if this really is useful.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 11 Dec 2004 03:47:49 -0800

> - Are these NATs that are helpfull common?

I've been trying to figure this out for awhile and I really don't think
anyone knows the answer to that questions. I have software that detects in
but have not yet run it on a ton of NATs. It is clear that 1) the vast
majority of NATs don't do this 2) there is more than 1 vendor that at one
time or another has shipped one that does.

"helpful" now there's a new word for them :-)