Subject: [MMUSIC] ICE Issue #15: Obfuscation of candidate lines from generic ALG

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Sep 2006 15:48:32 -0400

In rfc3489bis, we added the capability to return the mapped address in 
obfuscated form, by xoring it with the magic cookie. This is the 
XOR-MAPPED-ADDRESS. The reason this was done is that tests have shown 
that there are a class of NAT called 'generic ALG' which basically look 
for the binary coded version of the internal private address in the 
payload of a packet from inside to outside, and would rewrite it to the 
public address. This breaks stun.

It was pointed out that such nats do the same thing for ascii-coded 
versions of IP addresses. Thus, such a NAT would break ICE by rewriting 
the private address contained in the a=remote-candidate attributes. It 
was suggested that this can be fixed by changing the representation of 
the IP address to use exclamation points, and not periods. Thus:

10!0!1!1

instead of:

10.0.1.1

This won't actually help though. Lets say we do this, which allows 
checks to the private address. When the re-invite comes, the m/c-line 
(whcih still uses periods) would get modified, and there would be no 
matching a=candiadte attribute, which is bad.

Things actually work better if you simply let the ALG muck with the 
a=candidate attribute. In that case, the call will succeed, it just 
won't ever use the private address directly.

So my proposal is to do nothing about this.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   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: "Francois Audet" <[email-masked]>
Date: Wed, 13 Sep 2006 14:53:14 -0500

I agree.

I don't think we should go out-of-our-way to break ALGs on purpose. 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Wednesday, September 13, 2006 12:49 PM
> To: IETF MMUSIC WG
> Subject: [MMUSIC] ICE Issue #15: Obfuscation of candidate 
> lines from generic ALG
> 
> In rfc3489bis, we added the capability to return the mapped 
> address in obfuscated form, by xoring it with the magic 
> cookie. This is the XOR-MAPPED-ADDRESS. The reason this was 
> done is that tests have shown that there are a class of NAT 
> called 'generic ALG' which basically look for the binary 
> coded version of the internal private address in the payload 
> of a packet from inside to outside, and would rewrite it to 
> the public address. This breaks stun.
> 
> It was pointed out that such nats do the same thing for 
> ascii-coded versions of IP addresses. Thus, such a NAT would 
> break ICE by rewriting the private address contained in the 
> a=remote-candidate attributes. It was suggested that this can 
> be fixed by changing the representation of the IP address to 
> use exclamation points, and not periods. Thus:
> 
> 10!0!1!1
> 
> instead of:
> 
> 10.0.1.1
> 
> This won't actually help though. Lets say we do this, which 
> allows checks to the private address. When the re-invite 
> comes, the m/c-line (whcih still uses periods) would get 
> modified, and there would be no matching a=candiadte 
> attribute, which is bad.
> 
> Things actually work better if you simply let the ALG muck 
> with the a=candidate attribute. In that case, the call will 
> succeed, it just won't ever use the private address directly.
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 14 Sep 2006 09:41:03 +0200

Hi,

I agree with the proposal to do nothing.

Also, if you have a 'generic ALG' which modifies anything that looks
like a private IP address in the payload, won't it then also modify SIP
headers carrying the private IP address? In some cases it may not
matter, but it could have impacts on route sets etc.

Regards,

Christer

> Sent: 13. syyskuuta 2006 22:49
> To: IETF MMUSIC WG
> lines from genericALG

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Sep 2006 10:47:47 -0400

> matter, but it could have impacts on route sets etc.

I imagine it would, yes.

In any case ICE is certainly not the place for a broader treatment of 
whether such 'generic ALG' would break SIP or make it work.

-Jonathan R.