Subject: [MMUSIC] Comments to draft-ietf-mmusic-ice-07

From: <[email-masked]>
Date: Mon, 20 Mar 2006 05:37:17 +0200

Hi, 

I have two comments for new ICE I-D:

1. Use of MAPPED-ADDRESS attribute instead of XOR-MAPPED-ADDRESS

ICE expects candidate addresses be gathered from the MAPPED-ADDRESS
attribute of:

- STUN Allocate Response
- STUN Binding Response
  - as returned by the configured STUN server
  - as returned by the ICE peer

What is the reason that XOR-MAPPED-ADDRESS parameter would not be used
instead of MAPPED-PARAMETER in all of those three contexts ? I would
assume the original reasoning for introducing XOR-MAPPED-ADDRESS into
STUN to equally apply to those three cases within ICE:

      Discussion:  Some NATs rewrite the 32-bit binary payloads
      containing the NAT's public IP address, such as STUN's MAPPED-
      ADDRESS attribute.  Such behavior interferes with the operation of
      STUN and also causes failure of STUN's message integrity checking.

If such NATs have been implemented for the version of STUN introduced
in RFC 3489, I could assume that the same problem could also sooner or
later disturb the STUN responses sent for ICE. If you think this is not
the case please explain why.

2. Learning new candidates from connectivity checks

   The comparison of the source IP and port of the Binding Request and
   the IP address and port of the remote transport address in the
   matching transport address pair may indicate inequality.  In that
   case, the source IP and port of the Binding Request (and again, for
   relayed transport address, this refers to the source IP address and
   port of the packet when it arrived at the relay) are compared to the
   IP address and ports across the transport address pairs in *all*
   remote candidates.  If there is still no match, it means that the
   source IP and port might represent another valid remote transport
   address - a peer derived one.

I do not understand how the source IP address and port learned for the
relayed Binding Request could be valid peer derived remote transport
addresses. In general for peer derived addresses, the I-D says: 

   If an agent receives a STUN connectivity check with a new source IP
   address and port, or a response to such a check with a new IP address
   and port indicated in the MAPPED-ADDRESS attribute, this new address
   might be a viable candidate for the receipt of media.  This happens
   when there is a NAT with an address dependent or address and port
   dependent mapping property [37] between the agents. 

For the relayed Binding Request the source IP address and port of the
packet when it arrived at the relay are those that the NAT allocated
for the remote peer when it was communicting towards the STUN relay
server. So those addresses would only be usable for relayed packets,
instead of the other peer being able to access them directly.

Or does the "NAT with an address dependent or address and port
dependent mapping property" mean something else than "symmetric NAT" ?

Regards,

Erkki
____________________________________

  Erkki Koivusalo
  Nokia Mobile Software
  tel:+358 40 7571197
  mailto:[email-masked]
____________________________________ 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Mar 2006 09:35:29 -0500

Thanks for the comments. Responses inline.

[email-masked] wrote:

> instead of MAPPED-PARAMETER in all of those three contexts ? 

Ah! This is a bug. I had forgotten to make this change when switching 
from 3489 to 3489bis. It should always be XOR-MAPPED-ADDRESS for clients 
compliant with 3489bis. I'll make the change.

> I would

No, you are correct.

> server.

Right. And if the client is behind a 'symmetric' NAT - one whose binding 
policies are address and port dependent - that will be a new IP address 
and port.

> So those addresses would only be usable for relayed packets,

Yes. Peer derived candidates are only paired with the candidate they 
were sent to. So in your example above, the peer derived candidate would 
be paired with the relayed address.

> dependent mapping property" mean something else than "symmetric NAT" ?

If is different than symmetric NAT. One of the reasons behave abandoned 
the term 'symmetric nat' is that it encompasses several orthogonal 
properties, all of which were not necessarily present in NATs. Rather, 
NATs are defined by properties. The one of importance to peer derived 
address is the binding property, which determines which IP address and 
port are selected in an outgoing packet from the NAT. An 
address-and-port dependent (APD) binding property says that the binding 
that is used depends on both the destination IP address and port. Thus, 
packets sent to different destinations each get a different binding, 
which will trigger the peer derived mechanism.

The other property related to symmetric NAT is the permission property, 
which determines from where incoming packets will be accepted. An 
address and port dependent permission policy says that a NAT only 
accepts packets in if the client had sent packets out towards that 
IP/port. This property has no bearing on peer derived candidates.

HTH,
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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Mar 2006 17:52:48 -0800

...
> in RFC 3489,

One note on this:  the problem isn't that NATs have been implemented
to be aware of RFC3489 and are interfering with RFC3489 messages.  If 
that was the case, those NATs would also be implemented to be aware of 
XOR-MAPPED-ADDRESS and interfere with it, too.

Rather, the problem is that some NATs have extremely aggressive
application layer gateway functions and will rewrite any aligned
32-bit UDP payload that matches their public IP address to 
something else.  

See Christian Huitema's post on this point at:
http://www1.ietf.org/mail-archive/web/midcom/current/msg03510.html

The XOR protection allows STUN's various usages to work more 
reliably through such NATs.

> I could assume that the same problem could also sooner or
> later disturb the STUN responses sent for ICE. If you think 
> this is not the case please explain why.

For the benefit of the archives, Jonathan mentioned at the 
meeting that the misalignment of ICE and STUN around 
XOR-MAPPED-ADDRESS is a bug and that ICE will be adjusted 
to use XOR-MAPPED-ADDRESS.

-d