Subject: RE: Proposal for site-local clean-up

From: "Richard Draves" <[email-masked]>
Date: Tue, 19 Nov 2002 14:30:42 -0800

> > I think the vendor of one of
> > these devices should have the freedom to determine the 
> device's "out 
> > of the box" configuration, based on expected usage patterns.
> 
> Here I strongly disagree.  It's simply not reasonable in 
> general for a vendor to make assumptions about the 
> distribution of threats in 
> a customer's network.  For the very limited case of home 
> networks, it might be reasonable, but I have stong doubts 
> that either it's reasonable to define a  'home network' or to 
> have 'home network devices' as a special class that for which 
> it's declared okay to be insecure out of the box.

Not surprisingly, this reminds me of our discussion of "Default Address
Selection". :-) Obviously, an application or device must have *some*
"out of the box" configuration.

Unfortunately there is a trade-off between security & usability. One can
imagine several possible "out of the box" configurations. The first
would be no security, the app/device is accessible by all. From past
history & human nature we know that far too many users will fail to
configure the app/device. So this is not a good default configuration.
Another possibility is complete security - in other words, the
app/device is not functional until it is configured. The problem here is
that the annoyed user is most likely to "fix" the problem by disabling
security. Finally, an "out of box" configuration that relies on
site-locals offers some security with reasonable utility - not perfect
on either dimension but pretty good for most environments.

> I find this kind of thinking rather suspect. The
> question in my mind shouldn't be "why global", but
> "why not global".  There seems to an underlying
> assumption that site locals would give better
> security properties due to their global
> inaccessibility. I find that rather uncompelling
> and misguided as this is just carrying forth the
> broken assumption that barriers (firewalls, etc)
> can do an adequate job of protecting
> things. Anything which propogates that sort of
> thinking is, IMO (and almost certainly not in my
> employer's) bogus and needs to checked. We need
> keep beating the strong auth/authz drum here.

First, site-locals offer better security than a single firewall, because
typically there will be multiple routers on the path between an attacker
and a customer site, all filtering site-locals. Second, I agree that
strong security is great and we should work towards it. But "defense in
depth" argues for having multiple security mechanisms, so even with
strong security I think site-locals and firewalls have a place.

Rich

--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Wed, 20 Nov 2002 14:11:28 -0500

> security. 

I don't buy this argument, for several reasons.

I don't buy that having the vendor guess what works for the user and 
the user's network will be more secure overall than  asking the user
what the security policy should be.

Perhaps more importantly, I don't buy the argument that *any* set of
addresses should be considered trustworthy, by default or otherwise.   
Addresses are simply not sufficient as an authentication mechanism.  
This is not a practice that IETF standards should endorse or encourage.

The only exception that I can see is a device that has no keyboard or
display, and which must be configured over the net.  In those cases
I think it makes sense to allow the device to be configured from
another host on the same link - so the device would accept connections
to its linklocal or maybe site-local address until it was configured.  
But it should still require explicit configuration before allowing 
normal use if it has valuable resources to protect.

So if you are asking the question about which set of addresses should
be trusted by default, I claim you are asking the wrong question.

> and a customer site, all filtering site-locals. 

it doesn't follow, because you are only considering one kind of threat,
and you aren't considering other arguably more important aspects of 
security - such as the ability to detect breakins and attacks.

> Second, I agree that

actually, site-locals seem to make defense in depth more difficult.

Keith

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Nov 2002 04:01:32 +0100 (CET)

> strong security I think site-locals and firewalls have a place.

This assumes that ISPs will use site-locals. So far I haven't seen any
claims of benefits for ISPs to configure site boundaries and use site-local
addresses in their network.
If the ISPs don't use it the only boundaries would be at the attacker (which
might be able to control its site boundary) and at the attacked site, thus
no additional depth.

Any ISPs care to comment on this?

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 05:23:40 +0200 (EET)

> Any ISPs care to comment on this?

We surely don't use site-locals, never intend to, or never intend to block 
them in any way (except for standard ingress filtering).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 21 Nov 2002 19:32:18 +0100

On torsdag, nov 21, 2002, at 04:01 Europe/Stockholm, Erik Nordmark 

> Any ISPs care to comment on this?

As ex-ISP I agree. Just as basically noone is installing RFC1918 space 
today. Border will be at the ISP aggregation router or ISP controlled 
CPE.

- kurtis -