Subject: RE: Naming and site-local addresses

From: "Richard Draves" <[email-masked]>
Date: Mon, 11 Nov 2002 11:32:06 -0800

At the moment I believe we are stuck relying on two-faced DNS for
resolving names to site-local addresses. Luckily(?) two-faced DNS is
widely deployed.

There are other approaches. For example
draft-ietf-ipngwg-site-prefixes-05 was nice - among other things it
generalized easily to other name translation systems or more generally
to distributed apps that pass around addresses. But it has the problem
of not being backwards-compatible with existing implementations.

More recently (see the list archives around Oct 29) Mark Andrews has
proposed another way to put site-locals (and link-locals) in the DNS.

I agree that in practice to reduce complexity, site-local boundaries
should align with security boundaries.

Rich

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:[email-masked]] 
> Sent: Sunday, November 10, 2002 5:38 AM
> To: [email-masked]
> Subject: Naming and site-local addresses
> 
> 
> Forgive me if I am treading well-trodden paths here, but I am 
> trying to 
> understand....
> 
> It seems to me that using site-local addresses in 
> applications means that 
> applications have to get hold of these addresses somehow; very few 
> applications are fed addresses directly by their users.
> 
> 99% of applications do some kind of name-to-address lookup 
> *before* they 
> start getting into what kind of addresses to use. (And I'm not just 
> thinking about DNS - SDP is an example of a non-DNS 
> name-to-address lookup 
> - find the session using name/description, and pick the IP from the 
> description fields).
> 
> If a name-to-address lookup mechanism (ANY such mechanism) returns an 
> off-site site-local to the application, without the info that 
> this is an 
> off-site site-local, the application will not behave as 
> expected. (it will either connect to the address and fail, or 
> it will (worse) connect 
> to the address and succeed, but not to the point it wanted to go).
> 
> That seems to me to mean that the name lookup mechanism has 
> to not only 
> return globals and local-site site-locals, but has to 
> *suppress* off-site 
> site-locals.
> 
> Which again means that the lookup mechanism has to know the 
> scope identity 
> of BOTH the requester and the target resource, or choose to 
> return *no* 
> site-locals.
> 
> now, a lot of DNS is two-faced, meaning that the DNS servers 
> have to be 
> aware of scopes around them; mainly, two-faced DNS 
> distinguishes between 
> "within the security boundary" and "not within the security 
> boundary". But a lot of the DNS is not.
> 
> So using site-local with the DNS seems to require capturing 
> all DNS traffic 
> within the site, in case it tries to query for local resources, and 
> *keeping* it to DNS servers that know about the site of the 
> requester; this 
> would seem to mandate two-faced DNS, even when it's not necessary for 
> security, and, if security by firewall is in use, make it *extremely* 
> complex to configure site boundaries at any other place than 
> at security 
> boundaries.
> 
> This seems to me to be actually harder than configuring the 
> site border 
> routers for routing........ not nicely behaved wrt DNS at 
> all, and maybe 
> even less nicely behaved with other naming schemes...
> 
> This seems to lead me to one of two conclusions:
> 
> - Address lookup is significantly more complex in the presence of 
> site-local than if only global-scoped addresses are used
> 
> - I missed something.
> 
> Comments?
> 
>                     Harald
> 
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Michel Py" <[email-masked]>
Date: Mon, 11 Nov 2002 14:52:51 -0800

Hi Margaret,

>> Michel Py wrote:
>> It appears though that postings by different
>> people seem to converge about the idea that the boundaries
>> of the site (as in site-local) match the administrative
>> boundaries of the organization. There is an issue with
>> semantics but not with the concept itself.

> Margaret Wasserman wrote:
> Don't some sites have a DMZ where they put outward-facing
> servers that is actually outside their main security
> boundary?

I don't think so, see below.

> I don't think, though, that security boundaries and
> administrative boundaries always coincide.

Most of the time there is no such thing as a single "security boundary"
but multiple ones (I have seen six successive DMZs designs). Security is
_layered_, and I can't remember any network where one of the security
layers would not match the administrative boundary. Most of the time,
this would be the outer layer.

> So, would you put that DMZ outside the site, routing
> area and "two-faced" DNS boundaries, as well?

Not typically. The routing area and the security area will likely
include the DMZ as well as the site does. It is well understood that DMZ
hosts are sitting ducks, but it does not mean they should not be
protected by a firewall in order to prevent some attacks such as SYN/ACK
and ping of death. Therefore, they are within the security perimeter, on
the outside of it obviously.

Back to the diagram below, there is a security boundary that matches the
site boundary, another one in the outside firewall, another one in the
inside firewall, and finally one in router B. 

-------------------- Global Addresses ------------------><- SL addr ->
+-----+
| ISP |    |
+--+--+    |         :                :                 :
   !       |         :                :                 :
+--+---------+  +----------+     +----------+     +----------+
| Router A | +--+ Firewall +--+--+ Firewall +--+--+ Router B +---+
+------------+  +----------+  |  +----------+  |  +----------+   |
           |         :        |       :        |        :        |
           |         :    +---+--+    :     +--+---+    :   +----+----+
           |         :    | DMZ  |    :     | Host |    :   | Control |
           |         :    | Host |    :     +------+    :   | Device  |
           |         :    +------+    :                 :   +---------+
---Site -->|<-------------------------- Site ------------------------->
           |         :                :                 :
           |

A good security policy splits the administration of the different layers
because then one single person sleeping with the enemy can not
compromise the entire network. In the diagram above, if the
administrator responsible for router B wants to configure a tunnel in
router B in order to leak the site-locals, the tunneling protocol would
be blocked in the firewalls. Also, if the firewall administrator opens a
hole in the firewalls to get to the control devices, he can't because he
needs to reconfigure router B also.

Hope this helps,

Michel.