Subject: simple security

From: "Lee Howard" <[email-masked]>
Date: Tue, 23 Mar 2010 07:02:18 -0700

The simple-security draft represents the best practice we know of for
securing home networks.  It describes the behavior that should be the
default for all home networking gateways.  Advanced users who know what
they're getting into can change those default rules.

Some people argued that a stateful firewall is no longer needed because
attackers no longer use vectors that a firewall protects against.  This
sounds like circular reasoning to me, as if you no longer need a roof
because rain hasn't fallen on your head  for years.

It was also argued that attacks of this kind simply don't exist in IPv6.
That sounds like the argument that faults in the space shuttle o-ring
haven't caused explosions before, so it's safe.  I'll also point out that
OSes with smaller market share have fewer exploits written for them because
they are a smaller target; as IPv6 exceeds 50%, there will be more attacks.

I disagreed at the mike with the argument that ISPs should be doing this
kind of filtering themselves.  I'd like to understand that argument better.
If ISPs should be providing stateful firewall service, then doesn't that
support the need for a draft documenting what ISPs should do?   

Yes, hosts should provide better security for themselves.  In some regions,
users install three or four security packages on their computers, but even
their almost 50% of machines are infected.  Blocking the easiest paths to
exploits using perimeter security is current best practice, and should be
documented as such.

Lee

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Tue, 23 Mar 2010 10:39:17 -0400

Lee,

I agree. To amplify on your position, I offer the following. Many jurisdictions have draconian statues defining illicit Internet activity, e.g., child pornography, and associated stringent penalties, e.g., lengthy incarceration. If there is a perception that the use of IPv6 unique globally routable unicast addresses (UGA) increases a consumer's risk of inadvertently violating one of the statute because a compromise of their home systems or network, adoption of IPv6 by consumers will be minimal.

In addition, applying simple security controls such as least functionality is both sound and responsible. Specifically, if home networks are not supporting servers, e.g., web sites, then there is no need to allows sessions associated with servers to be initiated by Internet hosts.

Best Regards,

Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.
(301) 448-6965 (mobile)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lee Howard
Sent: Tuesday, March 23, 2010 10:02 AM
To: [email-masked]
Subject: simple security

The simple-security draft represents the best practice we know of for securing home networks.  It describes the behavior that should be the default for all home networking gateways.  Advanced users who know what they're getting into can change those default rules.

Some people argued that a stateful firewall is no longer needed because attackers no longer use vectors that a firewall protects against.  This sounds like circular reasoning to me, as if you no longer need a roof because rain hasn't fallen on your head  for years.

It was also argued that attacks of this kind simply don't exist in IPv6.   That sounds like the argument that faults in the space shuttle o-ring haven't caused explosions before, so it's safe.  I'll also point out that OSes with smaller market share have fewer exploits written for them because they are a smaller target; as IPv6 exceeds 50%, there will be more attacks.

I disagreed at the mike with the argument that ISPs should be doing this kind of filtering themselves.  I'd like to understand that argument better.  If ISPs should be providing stateful firewall service, then doesn't that support the need for a draft documenting what ISPs should do?

Yes, hosts should provide better security for themselves.  In some regions, users install three or four security packages on their computers, but even their almost 50% of machines are infected.  Blocking the easiest paths to exploits using perimeter security is current best practice, and should be documented as such.

Lee

---

From: Gert Doering <[email-masked]>
Date: Tue, 23 Mar 2010 15:48:38 +0100

Hi,

On Tue, Mar 23, 2010 at 10:39:17AM -0400, Dunn, Jeffrey H. wrote:
> Specifically, if home networks are not supporting servers, e.g.,
> web sites, then there is no need to allows sessions associated with
> servers to be initiated by Internet hosts.

Have you heard the term "peer-to-peer networking" mentioned before?

If all we want is "people can go from their home to web servers run by
professionals!!" then we don't need IPv6.

The whole point of having a new protocol is to restore end-to-end
communication - and that includes "people in their home" - VoIP, file
sharing, online gaming (without a server run in someone's data centre),
etc. - and if you put a deny-by-default firewall in their way, all
this won't work.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  150584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Tue, 23 Mar 2010 11:00:04 -0400

Gert,

I am not sure that denying incoming server sessions be default will inhibit all of those activities. It will inhibit unwanted file sharing, e.g., turning my machine into a child pornography web host. My wireless router has these filters on by default now. IMHO, it makes sense to provide the consumer with the same level of security they have with IPv4. 

As to home users accessing professionally developed web servers, you are correct that we do not need IPv6 for that; however, we do need UGA to allow those users to employ advanced security features, e.g., DNS SEC.

Best Regards, 
  
Jeffrey Dunn 
Info Systems Eng., Lead 
MITRE Corporation.
(301) 448-6965 (mobile)

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Tuesday, March 23, 2010 10:49 AM
To: Dunn, Jeffrey H.
Cc: Lee Howard; [email-masked]
Subject: Re: simple security

Hi,

Gert Doering
        -- NetMaster

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Tue, 23 Mar 2010 17:48:22 +0200

> they're getting into can change those default rules.

I've kept saying the same thing for three years now. But anyway. This 
assertion raises the a much more systematic question:

What's the use of IPv6 (then)? IPv6 with a stateful firewall is essentially 
just as bad as IPv4 with a NAT in terms of connectivity. Also IPv6 has 
fundamentally higher overhead (both in terms of packet header size and of 
router processing).

So the simple security draft seems highly paradoxical to me. A "solution" 
would be to specify a functional hole punching mechanism. But that key part 
part is missing. I am not comfortable with having the simple security document 
without a hole punching document too.

Some people will doubtless argue that there should not be a hole punching 
mechanism. But then, I would like them to answer the question above... 
(Standardization engineer job security is not a good reason for IPv6 to me)

> because rain hasn't fallen on your head  for years.

Do you take vaccinations for illenesses that don't exist anymore? Most people 
don't even take vaccinations for some that do exist but not where they live.

Why would you protect IPv6 systems for old (now fixed) vulnerabilities in IPv4 
systems?

> It was also argued that attacks of this kind simply don't exist in IPv6.

Which is true.

> haven't caused explosions before, so it's safe.

No. It's just an argument that operating systems have already been fixed 
*before* they implemented IPv6. Common attack vectors are in different 
(higher) parts of the software stack, against which stateful firewalls are 
totally helpless.

> I'll also point out that

That is a severe misrepresentation of reality. You will find exploits written 
for very obscure vulnerabilities. Of course, they are not commonly (mis)used, 
but they are available.

-- 
Rémi Denis-Courmont
Nokia Corporation / Maemo Devices R&D

---

From: Philip Homburg <[email-masked]>
Date: Tue, 23 Mar 2010 17:51:29 +0100

In your letter dated Tue, 23 Mar 2010 17:48:22 +0200 you wrote:
>Why would you protect IPv6 systems for old (now fixed) vulnerabilities in
>IPv4 systems?

Maybe I'm misunderstanding your argument. But are you trying to say that in,
say, the past 5 years, there have been no remote holes in any commonly used
system? 

Or are you trying to say to because remote holes are not exploited over IPv6
at the moment, it is not worth having protection for them. Just wait until
it is too late, and router vendors once again get a bad rep for offering
no security.

---

From: Fred Baker <[email-masked]>
Date: Tue, 23 Mar 2010 09:59:33 -0700

> don't even take vaccinations for some that do exist but not where they live.

Yes, and as a result we are seeing a resurgence of polio and other diseases.

I think the analogy applies perfectly.

http://www.ipinc.net/IPv4.GIF

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 23 Mar 2010 18:12:49 +0100

On Tue, 23 Mar 2010 17:51:29 +0100, Philip Homburg

>>Do you take vaccinations for illenesses that don't exist anymore? Most

>> people don't even take vaccinations for some that do exist but not

>> where they live.

> Maybe I'm misunderstanding your argument. But are you trying to say that

> in, say, the past 5 years, there have been no remote holes in any

commonly

> used system?

There are remote holes in old unpatched systems (which are generally so old

that they don't support IPv6 anyway). Oh sure, there are plenty of holes in

modern systems (that do support IPv6) but not the kind that stateful

firewalls protect against. Last time I checked stateful firewalls did not

protect from browser and web server bugs nor from harmful email.

-- 

Rémi Denis-Courmont

http://www.remlab.net

http://fi.linkedin.com/in/remidenis

---

From: Philip Homburg <[email-masked]>
Date: Tue, 23 Mar 2010 18:24:35 +0100

>protect from browser and web server bugs nor from harmful email.

So you are saying that the kinds of holes that stateful firewalls protect
against are only to be found in old systems, and somehow in the past years
the state of the art has advanced enough that new software has absolute none
of those holes?

Somehow, bugtraq seems to be full of all kinds of remote holes in current
systems.

A quote from just a random post:
"A remote attacker can read, list and retrieve nearly all files on
"the System remotely.  Required is a valid samba account for a share
"which is writeable OR a writeable share which is configured to be
"a guest account share, in this case this is a preauth exploit.

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 23 Mar 2010 11:14:00 -0700

I would tend to agree with Jeffery and Lee

Putting in baseline security from the outset would help protect the general
user base as they move to IPv6.  From an operators perspective, the average
person has no idea how networks operate, how to secure them, and frankly
don't care.  They expect things to work - i.e. Buy a PC, buy a home gateway,
pug it in and go.  I wish this was not the case, but wishful thinking gets
me nowhere.

I think that it's premature to assume the "home" network is ready for
unrestricted connectivity.  The dynamics of the "home" networks are changing
so fast, that the risks of this environment are not known.  Just because we
have not seen IPv6 based penetration and attacks as we have in the IPv4
space does not mean it won't happen (just give is time).  As an example, it
took a while from the inception of mass broadband connectivity (90s-2000s)
to finally see attackers lock on and begin to expose home environments based
on "always" on connectivity. (in the early days, many did not have home
firewalls or protective gateways)

Protecting the average person, with an option to "open" the cpe/gateway up
after provides a much safer framework.  Someone who decides to "open" up the
gateway after the fact would do so knowingly and be prepared (in theory) to
protect their network (OS patching etc).

No one has robbed me in my current house, but that does not mean I will stop
locking my door.  Sure they can come in through the window (which the few
robberies in my area have been though) - but if I stop locking my door, they
they will come in that way (much easier).

Victor K

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 23 Mar 2010 19:29:43 +0100

On Tue, 23 Mar 2010 18:24:35 +0100, Philip Homburg

> against are only to be found in old systems, and somehow in the past

years

> the state of the art has advanced enough that new software has absolute

> none of those holes?

So you are saying that IPv6 is useless?

(yes, I am also able to leverage selective quoting to my own advantage)

Why would I want to deploy IPv6 to my home if it's just like IPv4 but

slower and more expensive?

-- 

Rémi Denis-Courmont

http://www.remlab.net

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 23 Mar 2010 20:12:21 +0100

On Tue, 23 Mar 2010 11:14:00 -0700, Victor Kuarsingh

> unrestricted connectivity.  The dynamics of the "home" networks are

> changing so fast, that the risks of this environment are not known.

I said we need a ***hole punching*** mechanism.

Without hole punching application programmers will be stuck with UDP for

peer-to-peer use cases. And that's not good (I'd expect the IETF Transport

Area not be very happy with that, but IANAAD). No connection semantics, no

error correction, no flow/congestion control. If my memory is not failing

too badly, James Woodyatt also had a companion draft for that purpose. But

it's now defunct a document.

Then there is the proven issue that battery powered devices cannot cope

with stateful firewalling too well, unless the timeouts are long and

_known_. Typically they are short (especially for UDP). And with stateful

firewalling they aren't known. If the timeouts are not known, the

application ends up making the most pessimistic assumption (i.e. less than

30 seconds). That's not sustainable with the current battery technology,

and won't be for years to come if the experts of that domain are to be

trusted.

-- 

Rémi Denis-Courmont

http://www.remlab.net

---

From: Lindqvist Kurt Erik <[email-masked]>
Date: Wed, 24 Mar 2010 04:14:07 +0100

> (higher) parts of the software stack, against which stateful firewalls are 

If we believe that the attacks that today exist in IPv4 won't exist in IPv6 I think we are highly underestimating the investments in the underground economy. I am convinced we will see the same level of attacks and exploits for IPv6 as for IPv4. That said, I am not convinced that any security in the CPE will protect against that, just as NAT didn't protect in IPv4. However, I don't think that is the issue that we are trying to address with the simple security draft. 

Best regards,

- kurtis -

---

From: Lindqvist Kurt Erik <[email-masked]>
Date: Wed, 24 Mar 2010 05:15:03 +0100

> firewalls or protective gateways)

And here I think we have the core of the issue. I think we all agree that the advantages of IPv6 is more address space, and hence we can again restore end-to-end connectivity. However, at the same time we know that some network services are inherently insecure - IPv4 or IPV6. I would for example not run rsh on IPv6 just as little as I would over IPv4. From what I remember us discussing back in Philadelphia (I think it was) was that we need to agree on a minimum of these services that we believe should be filtered out. I'd like us to refocuse to that discussion - which services are we convinced we can block, and will provide additional security for the end-user (like rsh6) and at the same time not limiting future services for the end-user. 

So, as I see this - the entire discussion seems to have focused on the inbound traffic capability, where three options exists

1) Leave open and allow any traffic (that is not filtered on port) in

2) Only allow traffic that has been initiated from the inside to be passed through

3) Some hole-punching mechanism + 2)

Now, James said the next draft will make it clear this is not an IETF recommendation, just an outline of what you want to filter when you do advertise simple CPE security. 

Best regards,

- kurtis -

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 24 Mar 2010 17:39:08 +1100

> it's now defunct a document.

=> FYI We tried this in:
http://tools.ietf.org/id/draft-soliman-firewall-control-01.txt

There might be other proposals but I belief the strength of this proposal is
the effective plug n play security feature of CGAs.

Hesham

---

From: Mark Smith <[email-masked]>
Date: Wed, 24 Mar 2010 17:08:11 +1030

On Tue, 23 Mar 2010 11:14:00 -0700

> pug it in and go.  I wish this was not the case, but wishful thinking gets

And that is exactly why all end-node OSes have been shipped with
firewalls in the last 5+ years, enabled by default.

That is exactly why smart mobile phones haven't been widely exploited
when they've been directly attached to the Internet. They're shipped
with firewalls, enabled by default.

Laptops are outselling desktops. Laptops can and are directly attached
to foreign networks, including the Internet, without security
consideration.

People plug 3G dongles and similar straight into their laptops,
without any security consideration, and then straight into the Internet.

Put your hand up if you have a smart mobile phone. Now put it down if
you checked it had a firewall and it was enabled before you attached it
to a foreign untrusted network (like the IETF one). Hand still up?

The CPE/perimeter firewall model is based on an assumption of
constraints on mobility - your desktop PC stays on your desk, and stays
attached to the same home or work network. That assumption is
rapidly becoming less valid - people are going mobile, and therefore,
security models like the upstream CPE doing everything are becoming
both less valid and less reliable. Vendors have reacted by making the
devices themselves protect themselves. That trend is only going to
continue.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 12:15:49 +0100

On 3/23/10 3:02 PM, Lee Howard wrote:
> securing home networks.
It's not a best-practice, it's a best-guess.

Simple-security is being not being practiced at all on the vast majority 
of IPv6 residential connections today.

> It describes the behavior that should be the default for all home 
> networking gateways.  Advanced users who know what they're getting 
> into can change those default rules.
>
I'll argue the contrary.

Advanced users know how to manually poke holes in firewalls, run the 
right version of UPnP or NAT-PMP running, etc. Non-advanced users do 
not.  It's the non-advanced users that need protocols to "just work".

Firewalls make networking more frustrating, particularly for the 
non-advanced users.
>
> Some people argued that a stateful firewall is no longer needed 
> because attackers no longer use vectors that a firewall protects 
> against.  This sounds like circular reasoning to me, as if you no 
> longer need a roof because rain hasn't fallen on your head  for years.
>
If everyone has an umbrella and rain-suit anyway, what good is the roof 
doing?

Yes, I know there are still OSes that will be compromised in a matter of 
seconds on the open Internet. These, however, do not run IPv6. With 
IPv6, we are really talking about Vista, Win 7, linux, and macosx. All 
ship with IPv6 firewalls (except linux I suppose), and far more secure 
IP stacks vs. that of ten years ago. All have tethers back home for 
updates, in the event that a new exploit is found. These firewalls are 
far more adaptive and secure than the "IPv6 simple-security" firewall.

I don't want any of these new IPv6-enabled OSes to think for a moment 
that they can let their guard down just because they are plugged into a 
firewalled residential gateway "most of the time".
>
> It was also argued that attacks of this kind simply don't exist in 
> IPv6.   That sounds like the argument that faults in the space shuttle 
> o-ring haven't caused explosions before, so it's safe.
>
Bad analogy. The O-ring problem wasn't because of a hacker, it was 
human/engineering error in a complex system. A bug. Rather than 
protecting against bugs, firewalls increase the possibility of having 
more bugs.

> I'll also point out that OSes with smaller market share have fewer 
> exploits written for them because they are a smaller target; as IPv6 
> exceeds 50%, there will be more attacks.
>
Simple-security loses its effectiveness considerably for a home with no 
roaming devices. By the time IPv6 exceeds 50%, what do you think home 
networks will look like? The perimeter is getting very porous, and a 
"simple" firewall designed around the idea of a fixed home with 
stationary devices and a hard perimeter will be ineffective and obsolete.

This is why the only "firewall" I can consider for a moment to help with 
security is one that actively detects whether hosts inside the home as 
well as traffic coming from outside the home constitutes a security 
breach. The "security cop" on the edge isn't so much a device trying to 
black-hole traffic initiated from one direction or another, it is 
watching the traffic to see if devices in your home network are 
compromised or being attacked. This even works when the attack vector 
comes in via an email attachment, because it can watch the traffic 
patterns of an infected host connecting back to its lair and shut it 
down accordingly.

"simple-security" is "simple-minded". It is based on a security-model 
that is rapidly becoming obsolete, and comes at the cost of complexity 
in both the RG, the host, and the applications that have to try and work 
despite all the various rules for having their packets dropped.

> I disagreed at the mike with the argument that ISPs should be doing 
> this kind of filtering themselves.  I'd like to understand that 
> argument better.  If ISPs should be providing stateful firewall 
> service, then doesn't that support the need for a draft documenting 
> what ISPs should do?
>

The problem with any draft defining what kind of security an ISP or a 
gateway should do is that it is by definition a moving target. Security 
is, always has been, an arms race.

Which is why I think that if we should define anything it should be the 
base rules and interfaces for updating those rules in response to the 
threats. Any static document is going to be obsolete to the hackers 
before it is even becomes an RFC.

> Yes, hosts should provide better security for themselves.
>
One reason the older ones don't, is that nat-firewalls have provided 
protection for them during a time when hosts were mostly stationary and 
not updated regularly. Today, hosts must be able to deal with operating 
in a multitude of environments. The idea that I have a home with no 
roaming clients, or can sell an OS that cannot exist with or without a 
firewall protect it, is very much a 10-year-old reality.

If there is one advantage IPv6 does give us, is that it lets us draw a 
line between old IP stacks and the OSes they are attached to and new 
ones. It wouldn't be sensible for us not to exploit that.

> In some regions, users install three or four security packages on 
> their computers, but even their almost 50% of machines are infected.  
> Blocking the easiest paths to exploits using perimeter security is 
> current best practice, and should be documented as such.
>
Those regions probably need advanced-security, not simple-security. 
Simple-security with IPv6 probably isn't going to help that much, the 
hackers will still find their way in, as is clear from the infection rate.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 12:26:16 +0100

On 3/23/10 3:39 PM, Dunn, Jeffrey H. wrote:
>
> Lee,
>
> I agree. To amplify on your position, I offer the following. Many 
> jurisdictions have draconian statues defining illicit Internet 
> activity, e.g., child pornography, and associated stringent penalties, 
> e.g., lengthy incarceration. If there is a perception that the use of 
> IPv6 unique globally routable unicast addresses (UGA) increases a 
> consumer’s risk of inadvertently violating one of the statute because 
> a compromise of their home systems or network, adoption of IPv6 by 
> consumers will be minimal.
>
Someone would have to create the perception that UGA == increased threat 
of hosting child pornography.
>
> In addition, applying simple security controls such as least 
> functionality is both sound and responsible. Specifically, if home 
> networks are not supporting servers, e.g., web sites, then there is no 
> need to allows sessions associated with servers to be initiated by 
> Internet hosts.
>
The idea that the simple-security mechanism denies willing or protects 
unwilling users from hosting pornography would not be grounded in 
technical reality.

The IETF should not for a second help create this incorrect perception.

- Mark

PS. We have a SHOULD in the simple-security document for implementation 
of a protocol that allows a host to open a pinhole in the firewall on 
demand. If that comes into existence, running a web server is as readily 
possible with the firewall as without.

> Best Regards,
>
> Jeffrey Dunn
> Info Systems Eng., Lead
> MITRE Corporation.
>
> (301) 448-6965 (mobile)
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Lee Howard
> *Sent:* Tuesday, March 23, 2010 10:02 AM
> *To:* [email-masked]
> *Subject:* simple security
>
> o-ring haven't caused explosions before, so it's safe. I'll also point 
> out that OSes with smaller market share have fewer exploits written 
> for them because they are a smaller target; as IPv6 exceeds 50%, there 
> will be more attacks.
>
> Yes, hosts should provide better security for themselves. In some 
> regions, users install three or four security packages on their 
> computers, but even their almost 50% of machines are infected.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 12:34:23 +0100

> pug it in and go.  I wish this was not the case, but wishful thinking gets
Understand that firewalls make it *more* difficult for protocols to work 
over the Internet for the average user.

- Mark

---

From: Yannis Nikolopoulos <[email-masked]>
Date: Wed, 24 Mar 2010 14:23:18 +0200

On Wed, Mar 24, 2010 at 12:15:49PM +0100, Mark Townsley wrote:
> ship with IPv6 firewalls (except linux I suppose)

what about ip6tables?

Other than that, I think that the paragraph below sums up my feelings
for the matter

> despite all the various rules for having their packets dropped.

Yannis

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 13:22:11 +0100

> If we believe that the attacks that today exist in IPv4 won't exist in IPv6 I think we are highly underestimating the investments in the underground economy. I am convinced we will see the same lev…
Application level attacks will surely be the same.

L3/L4 attacks will match the vulnerabilities of the OSes under attack. 
90s and early-2000 era IPv4-only stacks are different than today's IPv6 
(and IPv4) stacks. There will definitely be overlap in both 
vulnerabilities and attack methods, but I still think it will be a 
subset of what we saw in yesteryear.

I do think that CPE security could protect against future attacks, just 
not the CPE security defined in draft-ietf-v6ops-simple-security...

- Mark

---

From: Mark Smith <[email-masked]>
Date: Wed, 24 Mar 2010 23:08:11 +1030

On Wed, 24 Mar 2010 12:15:49 +0100

> of IPv6 residential connections today.

Is that really the case? What is the current situation with IPv6
firewalls on mainstream OSes like OS X and Vista/Windows 7?

This Linux desktop is directly attached to the Internet, and I've been
running an IPv6 firewall on it for about 3 or 4 years. The initial
Linux implementation was a basic packet filter, however it became
stateful at least 18 months to 2 years ago.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 13:57:34 +0100

On 3/24/10 1:38 PM, Mark Smith wrote:
> Mark Townsley<[email-masked]>  wrote:
>
>    
By "simple-security" I was referring to the draft's scope, which is for 
residential gateways.
> stateful at least 18 months to 2 years ago.
Fully agree that most IPv6-enabled hosts are either running with some 
sort of firewall either enabled or at least available.

- Mark

---

From: Philip Homburg <[email-masked]>
Date: Wed, 24 Mar 2010 14:25:12 +0100

>far more adaptive and secure than the "IPv6 simple-security" firewall.

I think it is ironic that in one thread we are discussing devices that are
so resource constrained that they can't even afford to implement DHCPv6,
and have to rely on RFC-5006 to get the locations of DNS servers. And in
the next thread it is assumed that all devices have stateful firewalls and
automatically update themselves whenever a new bug is discovered.

Somehow that doesn't seem to add up.

Is it really that case that all that will be connected to the IPv6 internet
are Windows, Linux, and MacOS systems? No printers, no multi-media devices,
no light switches or other home automation systems? Or is every light switch
expected to come with it's own host-based firewall solution?

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 15:17:30 +0100

> automatically update themselves whenever a new bug is discovered.
Or simple-security for that matter.

I'm actually of the belief that the "dumb" RGs are on their way out 
anyway (and given uptick of actively SP-managed RGs in the world, I 
think there is evidence to support this claim).

For my part, the reason I support RFC 5006 moving to PS is because there 
is already running code that I see no intent of people turning off, 
coupled with the fact that architecturally I think DNS should have 
fallen in the SLAAC bucket of "the bare minimum to get IP off the 
ground" from the beginning. Nothing to do with CPU or Memory resources.

> expected to come with it's own host-based firewall solution?
If any of these devices get a global IPv6 address, I think they should 
be expected to operate on the Global IPv6 Internet in a secure manner. 
If they want to operate with link-locals or ULAs, they can expect that 
they are not part of the Global IPv6 Internet and act accordingly.

Otherwise, they are all stuck thinking that they "might or might not" be 
on the Global IPv6 Internet. No way to know, really.

- Mark

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 24 Mar 2010 15:36:42 +0100 (CET)

On Wed, 24 Mar 2010, Mark Townsley wrote:

> Simple-security is being not being practiced at all on the vast majority of 
> IPv6 residential connections today.

I experience is different. The IPv6 capable CPEs mostly supporting some 
form of firewalling. The dumb one's (only with 6to4) are not.

>
> Advanced users know how to manually poke holes in firewalls, run the right 
> version of UPnP or NAT-PMP running, etc. Non-advanced users do not.  It's the 
> non-advanced users that need protocols to "just work".
>
> Firewalls make networking more frustrating, particularly for the non-advanced 
> users.

Non-firewalling might cause even more frustration. You might remember case 
of pre SP2 Windows XP: you cannot update win XP without firewall since by 
the time you started to download SP ar patches your operating system was 
already compromised.... You might expect something similar in the future 
over IPv6 also.. There is a need for firewalling! The location of the 
firewall is a different story.

> seconds on the open Internet. These, however, do not run IPv6. With IPv6, we 
> are really talking about Vista, Win 7, linux, and macosx. All ship with IPv6 
> firewalls (except linux I suppose), and far more secure IP stacks vs. that of 
> ten years ago. All have tethers back home for updates, in the event that a 
> new exploit is found. These firewalls are far more adaptive and secure than 
> the "IPv6 simple-security" firewall.
>
> I don't want any of these new IPv6-enabled OSes to think for a moment that 
> they can let their guard down just because they are plugged into a firewalled 
> residential gateway "most of the time".

I think differently. I wrote one of my previous e-mail. Think about ipv6 
capable, but somehow limited or crap devices:

- no longer supported but know to be vulnerable devices, servers
- devices without access control

You need firewalling on these case at the CPE or with dedicated firewall.

> human/engineering error in a complex system. A bug. Rather than protecting 
> against bugs, firewalls increase the possibility of having more bugs.

No. Firewall can give time and possibility to fix some bugs later 
(unfortunately sometimes this time-window is infinite...)

>
> "simple-security" is "simple-minded". It is based on a security-model that is 
> rapidly becoming obsolete, and comes at the cost of complexity in both the 
> RG, the host, and the applications that have to try and work despite all the 
> various rules for having their packets dropped.

As simple minded as the current CPE. The residential gateway users are 
familiar with the the current IPv4 NAT behaviour. What they usuaally 
expecting - something similar for IPv6:
1. longer IP address? - understandable, but I don't care.
2. No NAT? - ok I get reasonable amount of subnet from my provider - If 
CPE copes with it, I don't mind.
3. No firewall? - what a hell? what will protect my extra-precious-hacked 
NAS? - They will sell a separate firewall for me? - No thanks!

Best Regards,
 	Janos Mohacsi

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 24 Mar 2010 16:44:44 +0200

> automatically update themselves whenever a new bug is discovered.

Any mobile device today could implement DHCPv6. Those are more powerful than 
the computers upon which IPv6 was trialed in the early days.

But anyway. A host-based firewall is most trivial to implement. Just don't 
send TCP/RST and ICMP port unreachable errors and you're done. In fact, it 
takes less resources to have a firewall than not to have one, in that respect.

Oh yeah, if you have a port open it will let traffic through. But that's why 
the port is open... to let traffic through. My 3G operator provides public IP 
addresses without inbound firewalling. My mobile phone has no open ports (or 
it had none until I explicitly installed SSH on it). From security point of 
view, the firewall would have no effect.

To be fair, the firewall would have one positive effect: my device would not 
need to wake up its radio interface when receiving bogus packets from the 
Internet. Those packets would be dropped before they get to the air radio 
interface. Personnally, I would in fact prefer firewall with hole punching 
either to firewall without hole punching or to no firewall at all.

> no light switches or other home automation systems? Or is every light
>  switch expected to come with it's own host-based firewall solution?

That goes the other way too: if those device can be connected to the Internet, 
we cannot assume they are firewalled because:
 - the firewall may be disabled (with your all-or-nothing firewall switch),
 - there may be no firewall (e.g. direct connection).
So those devices will have to protect themselves.

For things like printer and UPnP devices, ignoring connections *not* from 
private address space (e.g. fc00::/8) seems like a reasonable option. It does 
not hamper the connectivity of *OTHER* devices.

Also it won't make the printer suddenly vulnerable because *another* device 
needed the firewall disabled for the entire home network. That's what will 
happen if CPE ship with a "turn off the firewall" button on the HTTP 
interface. From a security perspective, having a firewall with:
 - a hole punching system (à la NAT-PMPv6), and/or
 - a non-routed ULA prefix inside the home,
seems a hell of a lot more secure than just a plain firewall in that respect.

-- 
Rémi Denis-Courmont

---

From: Philip Homburg <[email-masked]>
Date: Wed, 24 Mar 2010 15:56:48 +0100

>be expected to operate on the Global IPv6 Internet in a secure manner. 

I don't think anyone in the security community would find it reasonable
to expect all devices with global IPv6 address to operate in a secure manner.

There is more than enough evidence to suggest that in practice it will be
exactly the opposite.

And remember, in the typical SLAAC scenario any device that understands RAs
will automatically get a global IPv6 address, there is not much you can
do about it.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 16:12:53 +0100

On 3/24/10 3:36 PM, Mohacsi Janos wrote:
>>> The simple-security draft represents the best practice we know of 
>>> for securing home networks.
>>>
>> Simple-security is being not being practiced at all on the vast 
>> majority of IPv6 residential connections today.
>
> I experience is different. The IPv6 capable CPEs mostly supporting 
> some form of firewalling. The dumb one's (only with 6to4) are not.
At least according to Google's stats, the majority of users they see are 
from from Free Telecom, none of which are behind a firewall.

> Non-firewalling might cause even more frustration. You might remember 
> case of pre SP2 Windows XP: you cannot update win XP without firewall 
> since by the time you started to download SP ar patches your operating 
> system was already compromised.... You might expect something similar 
> in the future over IPv6 also.. There is a need for firewalling! The 
> location of the firewall is a different story.
Firewalls drop packets that legitimate applications would otherwise 
expect to be sent. They try also to drop packets from hackers. You can't 
expect them to always get it right.

So, by definition there is a tradeoff here. As is the case for pretty 
much every security measure in the world. Boarding a plane with or 
without the shoe inspection, etc.

Sure, you could say that not being blown up is a feature in usability so 
we should thank the TSP for making our traveling in the airport so much 
easier ;-)
>
>>
>> Yes, I know there are still OSes that will be compromised in a matter 
>> of seconds on the open Internet. These, however, do not run IPv6. 
>> With IPv6, we are really talking about Vista, Win 7, linux, and 
>> macosx. All ship with IPv6 firewalls (except linux I suppose), and 
>> far more secure IP stacks vs. that of ten years ago. All have tethers 
>> back home for updates, in the event that a new exploit is found. 
>> These firewalls are far more adaptive and secure than the "IPv6 
>> simple-security" firewall.
>>
>> that they can let their guard down just because they are plugged into 
>> a firewalled residential gateway "most of the time".
>
> I think differently. I wrote one of my previous e-mail. Think about 
> ipv6 capable, but somehow limited or crap devices:
>
Turn one on for those or don't put them on the global Ipv6 Internet. 
But, don't turn it on for every device in the world in the process. 
That's what I have been saying.

>> that is rapidly becoming obsolete, and comes at the cost of 
>> complexity in both the RG, the host, and the applications that have 
>> to try and work despite all the various rules for having their 
>> packets dropped.
>
>
> 2. No NAT? - ok I get reasonable amount of subnet from my provider - 
> If CPE copes with it, I don't mind.
> 3. No firewall? - what a hell? what will protect my 
> extra-precious-hacked NAS? - They will sell a separate firewall for 
> me? - No thanks!
Your NAS should run link-local or ULA if you don't want it to reach the 
outside world. If it needs a UGA for fetching its own updates, it 
shouldn't allow any incoming connections on it. If you are an expert 
user and want to setup accessing your NAS from the internet, you had 
better be sure it can handle being on the Internet because you'll be 
doing that anyway if you open a pinhole to it from your firewall.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 16:19:51 +0100

> either to firewall without hole punching or to no firewall at all.
This use of a firewall is perfectly legitimate because it is the link 
and interface itself that you are protecting. This is also illustrates 
how the hole punching method of operation begins to look essentially 
like a distributed IP stack between two devices. Gosh, I wish we had one 
(and only one) of those hole-punching protocols ready to go at the time 
of publishing this document.

Anyway, good technical point. Unfortunately, I don't see any discussion 
of this type in the current draft.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 16:27:42 +0100

> to expect all devices with global IPv6 address to operate in a secure manner.
"Secure" is a relative term.

Let me rephrase this to be that any device that configures a global IPv6 
address should expect that it may be connected to the global IPv6 
Internet and act accordingly.

> There is more than enough evidence to suggest that in practice it will be
Perhaps if more devices were exposed to the Internet, they would operate 
in a more secure manner.
> will automatically get a global IPv6 address, there is not much you can
But you don't have to open sockets that listen on that global address.

- Mark

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 24 Mar 2010 17:32:35 +0100 (CET)

On Wed, 24 Mar 2010, Mark Townsley wrote:

>>> "simple-security" is "simple-minded". It is based on a security-model that 
>>> is rapidly becoming obsolete, and comes at the cost of complexity in both 
>>> the RG, the host, and the applications that have to try and work despite 
>>> all the various rules for having their packets dropped.
>> 
>> 
>> familiar with the the current IPv4 NAT behaviour. What they usually 
>> 2. No NAT? - ok I get reasonable amount of subnet from my provider - If CPE 
>> copes with it, I don't mind.
> outside world.

How to configure the NAS for such a setup?
- If I use SLAAC? Do I have to prevent RAs with global prefix to be 
arrived to NAS? Do I have to filter on NAS? But what about the ULA? Do I 
get ULA via SLAAC? This requires a pretty complex setup.

- If I use DHCPv6? I have to configure DHCPv6 server not to distribute 
global address to NAS - only ULA...uh oh. Do we expect residential users 
to configure such a things in DHCPv6? in IPv4 they did not configure 
anything on DHCP..... Can I use DHCPv6 in every situation (if I use Mac 
OS X)?

- Do I have to put a different subnet the NAS than the computers to have 
separate address distribution policy? What happens to the discovery 
protocols - most of the NAS devices using some form of on-link discovery 
for setup applications?  Do I have to go thru the CPE in order to transfer 
files? The performance will be horrific....CPEs was not designed for such 
a task - packet forwarding between LAN and WAN side is done by a few 100 
Mhz processor - CPU power was selected by the limitation of broadband 
speed....

What setup do you think is working?

Best Regards,
 		Janos Mohacsi

---

From: james woodyatt <[email-masked]>
Date: Wed, 24 Mar 2010 10:15:24 -0700

> will automatically get a global IPv6 address, there is not much you can

It doesn't have to be that way.  Just because the RA contains a PIO with A=1 it does not mean that hosts MUST assign themselves an address in the prefix.  They certainly don't need to assign themselves a *persistent* address if they don't offer services in any directories.  Client-only hosts could restrict themselves to temporary global addresses on an as-needed basis.

So, you see, it's perfectly reasonable to say that minidevices that assign themselves persistent addresses with SLAAC unnecessarily and without being secured properly are in error.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Philip Homburg <[email-masked]>
Date: Wed, 24 Mar 2010 18:50:04 +0100

> It doesn't have to be that way.  Just because the RA contains a
> PIO with A=1 it does not mean that hosts MUST assign themselves an
> address in the prefix.  They certainly don't need to assign themselves
> a *persistent* address if they don't offer services in any directories.
> Client-only hosts could restrict themselves to temporary global
> addresses on an as-needed basis.
> 
> So, you see, it's perfectly reasonable to say that minidevices that
> assign themselves persistent addresses with SLAAC unnecessarily
> and without being secured properly are in error.

You seem to assume that devices like printers, multi media devices,
light switches, etc. are client-only device that have no need to communicate
unless prompted by the user.

In my experience, most of those devices tend to have server functionality 
that is always on.

---

From: Mark Smith <[email-masked]>
Date: Thu, 25 Mar 2010 06:51:11 +1030

On Wed, 24 Mar 2010 14:25:12 +0100

> expected to come with it's own host-based firewall solution?

A host based firewall can be a simple as a packet filter. For embedded
devices, an extremely simple yet fairly effective firewall would be to
only accept traffic from ULA source addresses.

---

From: Fred Baker <[email-masked]>
Date: Wed, 24 Mar 2010 13:31:47 -0700

On Mar 24, 2010, at 1:21 PM, Mark Smith wrote:

>> is every light switch

Speaking as the chair of the Security Subcommittee of the SGIP's Smart Grid Architecture Committee, my inclination would be to have the light controller be able to authenticate and authorize messages instructing it to modify the state of its light bulb, and determine whether they are from a switch that is authorized to initiate such messages. Absent that, I submit that the 21st century equivalent to TP'ing the house of the cute person-of-opposite-gender down the street might be to have their lights making statements using Morse Code.

---

From: Fred Baker <[email-masked]>
Date: Wed, 24 Mar 2010 13:36:25 -0700

By the way, I didn't invent this. Echelon, which is a company that is big in building automation, tells me that they do something along these lines today.

---

From: james woodyatt <[email-masked]>
Date: Wed, 24 Mar 2010 13:48:40 -0700

On Mar 24, 2010, at 13:36, Fred Baker wrote:
> I submit that the 21st century equivalent to TP'ing the house of the cute person-of-opposite-gender down the street might be to have their lights making statements using Morse Code.
> [...]

Which reminds me of a YouTube video that might lighten some hearts:

  <http://www.youtube.com/watch?v=0L7DTMKekoU>

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 22:05:40 +0100

> Speaking as the chair of the Security Subcommittee of the SGIP's Smart Grid Architecture Committee, my inclination would be to have the light controller be able to authenticate and authorize messag…
As such, you wouldn't rely on firewall between the two to secure the 
light controller. The security needs to be between the controller and 
switch, not policed by a middlebox function dropping packets it thinks 
might be from a rogue source without *really* knowing.

I agree wholeheartedly with this security model.

- Mark

---

From: Lindqvist Kurt Erik <[email-masked]>
Date: Wed, 24 Mar 2010 19:26:44 +0100

On 24 mar 2010, at 13.22, Mark Townsley wrote:

> L3/L4 attacks will match the vulnerabilities of the OSes under attack. 90s and early-2000 era IPv4-only stacks are different than today's IPv6 (and IPv4) stacks. There will definitely be overlap in both vulnerabilities and attack methods, but I still think it will be a subset of what we saw in yesteryear.

I would agree with this, but I also think that the current simple security draft does address that overlap. 

> I do think that CPE security could protect against future attacks, just not the CPE security defined in draft-ietf-v6ops-simple-security...

Could you elaborate in more detail what you think should change? 

Best regards,

- kurtis -

---

From: Mark Townsley <[email-masked]>
Date: Thu, 25 Mar 2010 08:59:36 +0100

> I would agree with this, but I also think that the current simple security draft does address that overlap.
It mimicks IPv4, so addresses quite a bit more than just the overlap.
> Could you elaborate in more detail what you think should change?
draft-vyncke-advanced-ipv6-security-01 is a start.

Also, simply letting people know that running without an IPv6 firewall, today, is not as dangerous as running without an IPv4 firewall, today.

- Mark

---

From: Konrad Rosenbaum <[email-masked]>
Date: Sun, 28 Mar 2010 17:41:45 +0100

> get ULA via SLAAC? This requires a pretty complex setup.

If I would build the NAS I would let it operate as usual, but add a few 
simple packet filter rules to the rudimentary firewall inside the device: 
allow absolutely everything out; allow everything in that targets me at 
fe80::/10; allow everything in that targets me at fc00::/7 if it comes from 
a locally advertise network, do not allow anything else in. I would also 
give the user an option to disable the packet dropping code (if I felt too 
lazy to implement a proper configuration). I wouldn't expect the router or 
any other device to protect or fool my NAS device.

Maybe someone needs to define a few more simple-security rules for devices 
other than CPE gateways?

I don't really see an incentive for device engineers to put proper security 
into "dumb" devices if there is no spec - they are used to letting 
the "magic of NAT" take care of this.

	Konrad

---

From: Mark Townsley <[email-masked]>
Date: Sun, 28 Mar 2010 19:06:32 +0200

> Maybe someone needs to define a few more simple-security rules for devices
Not a bad idea at all. Security certainly doesn't start or stop at the 
gateway.

> the "magic of NAT" take care of this.
Agreed. If the applications (or devices built for a specific 
application) were a bit more aware of the scoping of an IPv6 address, 
perhaps they could use this for better security, not to mention ease of 
use.

These problems aren't easy, and probably require peeking into APIs and 
such to be done properly, but perhaps this is where our efforts should 
be directed.

- Mark

---

From: [email-masked]
Date: Sun, 28 Mar 2010 22:04:59 +0300

>application) were a bit more aware of the scooping of an IPv6 address,

>use.

As in the simple-security the SOHO users are concerned, could it make sense to give them the opportunity to define the scope of both the CPE and the end user equipment?

In case of NAS, considering that some sort of initial config might be needed, a Home Mode vs Internet Mode might make sense.

The same thing with the CPE, a dropdown with Home Mode (to connect NAS devices for example), Internet Protected Mode (for those who want simple security), Internet Unprotected Mode (for no security), under each wire port could make the feature easy to market.
It is a little bit more complex with wireless connectivity in the CPE alone as it would require the user to somehow define the device scope manually, which is not the way things should work. I could think about using different SSIDs but that does not sound smooth either.

Roman

---

From: Mark Smith <[email-masked]>
Date: Mon, 29 Mar 2010 06:57:28 +1030

On Sun, 28 Mar 2010 19:06:32 +0200

> perhaps they could use this for better security, not to mention ease of 

As much as I think using ULAs for this is a good simple solution, one
model I've thought could be better is the "association" model used by
bluetooth or DECT handsets and base stations. If you setup an
trusted association between devices, via some sort of enrolment
process (e.g. press a button on both devices at once, then acknowledge
the relationship), probably with an expiry period (to allow short
term trust e.g. temporary access to your printer for a day), the access
to devices could then be addressing independent. Following that model,
you could access your home NAS, fridge etc. from any location, ULA or
global.

Regards,
Mark.

---

From: Gert Doering <[email-masked]>
Date: Sun, 28 Mar 2010 22:44:11 +0200

Hi,

> you could access your home NAS, fridge etc. from any location, ULA or

Hear hear.

I'm all for that.  Time to leave the encrusted IPv4 models behind.

(The whole model of "listing specific IP addresses in firewalls to
define who is allowed to do what" is something we've learned to accept,
because we do not have anything better, but that doesn't make it any
more useful.  Think "renumbering networks" and "firewall rules in
other people's firewall tables"...)

Gert Doering
        -- NetMaster

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 29 Mar 2010 09:18:45 +0200 (CEST)

On Sun, 28 Mar 2010, Konrad Rosenbaum wrote:

> a locally advertise network, do not allow anything else in.

This does not prevent the NAS and clients to pick up global addresses. The 
current RFC 3484 does not cope properly with ULA addresses, so therefore 
there are some risk for no working setup witch such a filtering on NAS: 
nas-client and nas-server has both ULA and global ipv6 address. If the 
nas-client want to use global address to reach nas-server, then it will 
fail.

> the "magic of NAT" take care of this.

There is a user expectation: my devices was protrected by IPv4-NAT/CPE , 
then similar should happen with IPv6....

However I am not favor of firewalls....

Best Regards,
 		Janos Mohacsi

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 29 Mar 2010 11:20:33 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mohacsi Janos
Sent: Monday, March 29, 2010 12:19 AM
To: Konrad Rosenbaum
Cc: [email-masked]
Subject: Re: simple security

>The current RFC 3484 does not cope properly with ULA addresses, 

What do you mean by not cope?  ULA and the GUA have global scope and the
longest prefix match works fine for packet forwarding if both a ULA and
a GUA are configured on a network interface.  I don't see any gotcha
with RFC 3484 with use of ULA or with use of ULA and a GUA on a network
interface.

Hemant

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 29 Mar 2010 18:37:33 +0200 (CEST)

> with RFC 3484 with use of ULA or with use of ULA and a GUA on a network

Yes. You are right, but in the context, that I wrote I don't see it is 
enough. If you have two nodes with both GUA and ULA, but different 
subnets inside a site:

[node1]----------[router]---------[node2]

Both GUA and ULA addresses are configured in the DNS...

What to configure no node1 and node2 to prefer ULA communication between 
node1 and node2?

And contrary, if I want prefer GUA usage between nodes?

Can I do it with the current default RFC 3484?

In the default policy table
       Prefix        Precedence Label
       ::1/128               50     0
       ::/0                  40     1
       2002::/16             30     2
       ::/96                 20     3
       ::ffff:0:0/96         10     4

Best Regards,
 		Janos Mohacsi

---

From: Fred Baker <[email-masked]>
Date: Mon, 29 Mar 2010 10:23:45 -0700

The default table, as you point out, doesn't specifically reference FC00::/7; it prefers localhost to any IPv6 address, any IPv6 address to a 6to4 address, and 6to4 to any IPv4/IPv6 translation mechanism using a well known prefix. As such, the next rule will apply. The next rule, as I understand it, will be to order the available addresses by the length of their matching prefixes from longest to shortest.

I would expect, given that scenario, that if we are within the same edge network (the most common use of ULAs), we will have at least one and perhaps several prefixes that are longer than /48, and the exact choice will be specific to the address pair being compared but may choose the ULA. If we are not in the same network but share PA prefixes from an ISP, we are likely to use that ISP's prefix. if we do not share prefixes allocated by an ISP, your guess is as good as mine.

I would actually not suggest adding FC00::/7 to the default table; if some system on the other side of the world is advertising a ULA in DNS and you have one, you'll try ULA-to-ULA in preference and you won't be happy with the result. However, you might add your own ULA within your domain in preference to ::/0.

On Mar 29, 2010, at 9:37 AM, Mohacsi Janos wrote:

> Yes. You are right, but in the context, that I wrote I don't see it is enough. If you have two nodes with both GUA and ULA, but different subnets inside a site:
> 
> 
> What to configure no node1 and node2 to prefer ULA communication between node1 and node2?
>

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 30 Mar 2010 10:38:55 +0200 (CEST)

On Mon, 29 Mar 2010, Fred Baker wrote:

> The default table, as you point out, doesn't specifically reference 
> FC00::/7; it prefers localhost to any IPv6 address, any IPv6 address to 
> a 6to4 address, and 6to4 to any IPv4/IPv6 translation mechanism using a 
> well known prefix. As such, the next rule will apply. The next rule, as 
> I understand it, will be to order the available addresses by the length 
> of their matching prefixes from longest to shortest.
>
> I would expect, given that scenario, that if we are within the same edge 
> network (the most common use of ULAs), we will have at least one and 
> perhaps several prefixes that are longer than /48, and the exact choice 
> will be specific to the address pair being compared but may choose the 
> ULA. If we are not in the same network but share PA prefixes from an 
> ISP, we are likely to use that ISP's prefix. if we do not share prefixes 
> allocated by an ISP, your guess is as good as mine.
>
> I would actually not suggest adding FC00::/7 to the default table; if 
> some system on the other side of the world is advertising a ULA in DNS 
> and you have one, you'll try ULA-to-ULA in preference and you won't be 
> happy with the result. However, you might add your own ULA within your 
> domain in preference to ::/0.

Agreed. I just wanted to mention in one of my previous e-mail regarding 
CPE simple security - CPE without firewall: Usage of ULA behind the CPE 
instead GUA not very trivial. Needs some tweaking to prefer own ULA or 
RFC3484 policy distribution.

Best Regards,
 	Janos Mohacsi

---

From: Fred Baker <[email-masked]>
Date: Tue, 30 Mar 2010 13:39:36 -0700

Using a ULA *instead* of a GUA makes sense for all the systems that you only want to access or to have access within the domain. In my house, I think that is two of them, both printers, and one of those is USB-attached rather than being IP-attached. The blue-ray player needs to be able to download from Netflix, the set-top box needs to talk with Cox for content and control, and then there are those pesky computer things.

On Mar 30, 2010, at 1:38 AM, Mohacsi Janos wrote:

> Agreed. I just wanted to mention in one of my previous e-mail regarding CPE simple security - CPE without firewall: Usage of ULA behind the CPE instead GUA not very trivial. Needs some tweaking to prefer own ULA or RFC3484 policy distribution.
> 
> Best Regards,
> 	Janos Mohacsi
> 
> 
>>