Subject: [RAM] Application use of locators

From: Ted Hardie <[email-masked]>
Date: Mon, 2 Apr 2007 13:09:13 -0700

On several occasions, folks have asked for specifics of application
use of locators in referrals.  It might be useful for those wanting to
see one edge of this to review:  http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt .  It's a long spec, but it includes a good bit that is worth thinking
through; in particular, it has replied to the IAB's Unilateral Self-Address Fixing
(unsaf) document in some detail.  It does not go fully into why it uses
locators, saying:

   Protocols using offer/answer are difficult to operate through Network
   Address Translators (NAT).  Because their purpose is to establish a
   flow of media packets, they tend to carry the IP of media sources and
   sinks within their messages, which is known to be problematic through
   NAT [16].  The protocols also seek to create a media flow directly
   between participants, so that there is no application layer
   intermediary between them.  This is done to reduce media latency,
   decrease packet loss, and reduce the operational costs of deploying
   the application.  However, this is difficult to accomplish through
   NAT.  A full treatment of the reasons for this is beyond the scope of
   this specification.

Despite this limitation, there is a lot here to show the extent to which
an application will go to attempt to discover its place in the topologies of
which it is part, in order to make its own routing decisions.  I say
routing here because I believe the application's choice of outbound
interface is being treated like a next-hop decision in this context.

Reading through the draft, it is moderately obvious that this is not how David Conrad
would have done this (Your WWDRCDO? bracelet available now at Cafe Press).
In a world in which the DNS protocol could be used to its fullest, the two end
nodes which wished to use an offer-answer mechanism could do so
either using some weight-contain record (an S-NAPTR record, say), a series of
related records, or even fast-moving updates to a single DNS record
like an A or AAAA per side.  Even if all of those approaches are stupid,
it is likely that some id/locator split based on the DNS is possible in
this case.

So, why wasn't that the approach taken here?  I have two speculations,
which may have implications for further thought here.

Speculation one:  split DNS generally hasn't been done well.  Split DNS
means that the data you get out of the DNS is different depending on where
in the network topology you are when you ask the question.  Updating
records in the presence of split DNS presents a policy problem, as it is
difficult to determine which side(s) of the split DNS should get the updates.
While it would theoretically be possible for a node at RFC 1918 address
10.0.2.3 to update its A record to its STUN-determined external address
of 66.160.187.27, this just doesn't seem to work in a lot of the DNS
deployments out there today.  That means that an end node trying to use
the DNS to communicate how it is reachable may not be able to 
do so effectively, especially since the seams in the split DNS are not
exposed to the end node for discovery.

Speculation two:  even if speculation one's problem were corrected, the 
connectivity check problem would remain.  As the draft puts it:

   The second property is important for getting ICE to work when there
   are NATs in front of L and R. Frequently, NATs will not allow packets
   in from a host until the agent behind the NAT has sent a packet
   towards that host.  Consequently, ICE checks in each direction will
   not succeed until both sides have sent a check through their
   respective NATs.

This policy institution is aimed to avoid stupid bad guys from port-scanning
weak hosts.  If NATs were done away with, I strongly suspect that this
functionality would be shifted to firewalls (many of which also have this
characteristic).  The connectivity check problem means that even if 
I somehow succeed in telling you an external address at which I should
be reachable, I need to enable that address's validity *for flows from
some other specific point in the topology*, or the network will not
route the packets.  That's not lovely, but it is likely reality.

I have some potential conclusions from those speculations, but I'd like to
hear others' thoughts on the ICE architecture before I make a fool of
myself (after all, I might have some much larger way of doing so with
the extra help).
			regards,
				Ted Hardie

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Apr 2007 13:26:34 -0700

Ted,

Replying to just one aspect of your interesting post: 

> in particular, it has replied to the IAB's Unilateral
> Self-Address Fixing (unsaf) document in some detail.

Here is what (RFC4380, Section 8.4) has to say about UNSAF,
which more or less matches the IPvLX paradigm:

  "Our experience with Teredo has led to the following requirements for
   a long-term solution to the NAT problem: the devices that implement
   the IPv4 NAT services should in the future also become IPv6 routers."

Fred
[email-masked]