Subject: CPE equipments and stateful filters

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 24 Jul 2007 04:36:10 +0900 (JST)

on CPE equipments and stateful filters.

	first of all, here's my take on NAT and access controls at the border.
	(i've posted this URL to ietf@ietf couple of days ago)
	http://ipv6samurais.com/ipv6samurais/demystify/

	NAT or stateful filters w/ ALG are not future proven (cannot accomodate
	new protocols and people needs to upgrade forever).
	because of this reason NAT-PT document is deprecated in v6ops.
	now we are seeing the opposite action.  weird.

	i do not disagree with "we need stateful filter implementations".
	but i suggest that we need to be REAL careful about the default
	settings.  otherwise your cellphone that have roamed into your home
	network, and/or TiVo device, cannot be used from the outside.
	(i dislike UPnP, yeah)

	Fred raised concerns about DoS attack, but if you run secure OS
	you do not have to worry about that.  issues like DNS reflection attack
	are being mitigated by protocol changes, and/or bind config changes.

	tnx.

itojun
PS: i am a person who eat one's own dog food.  i do not have any kind of
firewall in my home!

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 24 Jul 2007 04:40:47 +0900 (JST)

> 	http://ipv6samurais.com/ipv6samurais/demystify/

	oops, past tense.
	http://ipv6samurais.com/ipv6samurais/demystified/

itojun

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Jul 2007 14:53:03 -0500

> PS: i am a person who eat one's own dog food.  i do not have any  

For the record, I don't use any stateful filtering on my home  
network, either.

(I *do* think some stateless filtering is appropriate, mainly those  
things in section 3.1 of draft-ietf-v6ops-cpe-simple-security.  I  
suspect you'll regard R3 with particular approval, but I could be  
mistaken...)

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

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 23 Jul 2007 21:00:08 +0100

> 	on CPE equipments and stateful filters.
[..]

> 	network, and/or TiVo device, cannot be used from the outside.

I am actually starting to believe that we really need a secure protocol
ala uPnP for requesting 'privileges' for sending packets over a network
border, current NAT boxes/gateways.

Lets say I am sitting behind my laptop, and I want to go to
www.wikipedia.org (http over tcp, port 80) then my host should 'ask' a
$device on the network if I am allowed to make a TCP connection to port
80 of www.wikipedia.org. $device in the network then gives me a tag
saying 'here you go' and distributes this tag also to the firewalls that
are in the network to allow traffic tagged with this through. All
packets outbound will be tagged with this special tag. Then when packets
come back from wikipedia, it can also add the same tag, the firewall
then at least knows that this is related traffic, it can lookup the tag
in its tables and sees that indeed my host was talking to wikipedia and
that it is likely return traffic and pass it through. One can also
request a tag for 'generic HTTP traffic (port 80/tcp) etc. Depending on
how strict one would set these filters the tags could be more specific
or not.

Similarly, eg FTP, my host asks $device for port 21 access to
ftp.heanet.ie, gets a tag, then inside the protocol the remote host
needs to connect to me, thus my host asks for this access from $device.

One really nice side effect of 'tagging' all the traffic, which is a bit
overhead, but hey we still have a flowlabel, is that we have in $device
a list what the traffic is actually for. When requesting the tag, the
protocol that handles this can actually have information added to it
like username, content, requesting program/pid/exe-location and a lot
more. For network administrators, and especially people who are careful
about virusses, it will be very nice as the logs will then give a bit
more information detailing where traffic comes from.

The flowlabel/tag can be src/dst specific, as such we have a
src+dst+flowlabel combo. Even IPSec'd traffic can then also be accounted
for, which will make accounting people really happy.

Only the endhosts then need to know how the protocols actually work, the
$device only needs to apply policy, which for a home network might be as
simple as "allow everything" to a corporate "only port 80 to wikipedia"
and only when the request is fully authenticated with kerberos.

Having layers, thus different administrative realms, might get a bit
tricky with this though, one would then have to forward the requests on
to the other realms and possibly change the tag depending on in which
realm the packet is at that moment.

Greets,
 Jeroen

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 24 Jul 2007 05:04:16 +0900 (JST)

> border, current NAT boxes/gateways.
(snip)

	again, it is better to be raised in IAB plenary i guess.

	that is "signalling for everything" model, i.e. telco model....
	how can you identify which router between you and www.wikipedia.org
	you need to contact for a permission to connect?

itojun

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Jul 2007 15:22:23 -0500

On Jul 23, 2007, at 14:36, Jun-ichiro itojun Hagino wrote:
>
> otherwise your cellphone that have roamed into your home network,  
> and/or TiVo device, cannot be used from the outside.

Alas, my cellphone provider isn't particularly interested in letting  
my phone make and receive SIP calls over my home 802.11 wireless  
network routed to the Internet.  I fear you're pointing out a  
*feature*, not a bug.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 24 Jul 2007 05:31:22 +0900 (JST)

> network routed to the Internet.  I fear you're pointing out a  

	well, your cellphone network provider may not, but nokia have
	already shipping phones with SIP and IPv6: E61 and those series.
	any comments from ericsson? :-)

itojun

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 23 Jul 2007 21:32:05 +0100

> 	again, it is better to be raised in IAB plenary i guess.

It is indeed a much more structural change of how "The Internet" would
behave, but in combo with the changed usage of IP over the years, future
assumptions, current ID/LOC proposals, the requirements for tracking
things etc etc, I guess something like that whill one day be the way
that it will have to go before it turns into a complete and total mess
that we can't control at all anymore and rampant things like "blocking
port 25" will become very extremely common place.

> 	you need to contact for a permission to connect?

Same way that eg uPnP does. One can always use mDNS or DNS+DNSSec to
figure it out, get it through DHCP, a lot of other methods. In a big
corp network one also already have to figure out what the authentication
service is anyway at the moment, can use that too, one has to
authenticate it anyway.

It indeed because quite though when you have multiple layers of
administration (read different firewall admins) between $src and $dst,
one concept there would be forwarding the requests on to the next layer.
(obligatory Shrek reference: onions have layers), thus in a home network:
  $user -> "jeroen wants to go to wikipedia" -> $homegate
  $homegate -> "customer X wants to go to" -> $isp

which can lead into a policestate and most likely again a lot of
protocols simply running over port 80 encapsulated in HTTP when certain
things you expect to work would be blocked. At least in the above
scenario $homegate would get back a "no you are not allowed to use port
25" message from the ISP with most likely a URL to the helpdesk page
that explains it etc etc.

Greets,
 Jeroen

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Jul 2007 15:44:26 -0500

> 	any comments from ericsson? :-)

I would expect that those cellphones would have really lousy battery  
life while they were continually sending bubble packets at their SIP  
registration servers in order to keep their packet filter state  
alive.  I know of at least one mobile phone maker who isn't using SIP  
and IPv6 in their handsets because IEEE 802.11 PS-mode is pretty  
pointless when you have to wake up and do keepalives so frequently.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 24 Jul 2007 05:44:57 +0900 (JST)

> port 25" will become very extremely common place.

	(off topic, i know)
	in my opinion ID/LOC stuff is all wrong.  IP address is always locator
	and you have to use X.509 certs or ssh host key for IDs.
	IAB has bee tntrying very hard to keep the important design decisions
	made by early pioneers.  of course some of them has to be updated, but
	it is in my firm belief that many of the old sayings are right.

> service is anyway at the moment, can use that too, one has to

	as far as i understand UPnP is on-link only (correct me if i'm wrong).

	you do not get my point: there could be multiple enforcement points
	that may block your traffic.  how can you ask for ALL of them to allow
	your http traffic.  this is a policy thing so the way how to ask it
	could be different, the way how to deploy your proposal would be real
	hard just like intserv suffered.
	if you know of intserv deployment across huge number of independent
	ASes, let me know.  i'm curious.

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 24 Jul 2007 05:50:14 +0900 (JST)

> pointless when you have to wake up and do keepalives so frequently.

	as far as i understand, nokia/ericsson are so active in IPv6 and
	mobile-ipv6 arena because they are trying to push the idea of all-IP
	cellphones.  of course it does not have to be 802.11-based, but
	i guess they would like to get rid of all the expensive PBXes,
	so as NTT Docomo.  of course i'm not speaking for them.

	what kind of device the next generation iPhone would be :-)

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jul 2007 01:48:02 +0200

On 2007-07-23 21:36, Jun-ichiro itojun Hagino wrote:
> 	settings.  

I agree. But the market reality (and we heard it explicitly from a
well known CPE vendor at the microphone) is that they will not sell
$50 consumer gateways that allow incoming unsolicited SYN or UDP
by default. We need to make realistic recommendations in that context.

    Brian

---

From: Christian Huitema <[email-masked]>
Date: Mon, 23 Jul 2007 17:26:17 -0700

> by default. We need to make realistic recommendations in that context.

Well, look then at what will happen. Application providers will deploy infrastructure that mixes Teredo, STUN, ICE and what have you to ensure that stations beyond the CPE can indeed receive unsolicited SYN and UDP packets. So, instead of doing the simple thing, i.e. turn off the damn filters by default, we will get an arms race that results in exactly the same security posture, but simply costs a lot more. Predicting the arms race is maybe more realistic than trying to avoid it, but it certainly is not better engineering.

-- Christian Huitema

---

From: Perry Lorier <[email-masked]>
Date: Tue, 24 Jul 2007 15:21:13 +1200

> border, current NAT boxes/gateways.

So who do we ask for these privileges?

The OS?  Well that already has veto privileges, and as past history 
shows it's easily circumvented.

The end users CPE?  A dinky little device with no real UI other than 
perhaps a web server and no way to beg for extra help.  (What's it going 
to do?  blink a light at me to say it doesn't like something?  Besides 
it's locked in a cupboard, do I have to walk to the other end of the 
house to see if it's unhappy?)

The end users CPE could ask the ISP, is the ISP really going to want to 
take the responsibility of authorising every single transaction on the 
Internet?  Are they going to be in a position to understand what the 
users trying to achieve?

The remote users firewall?  Goodness knows what this is supposed to do, 
and already has power of veto with firewalling.

I still don't see the point in any of this stuff.

---

From: Fred Baker <[email-masked]>
Date: Tue, 24 Jul 2007 10:34:46 -0500

On Jul 23, 2007, at 2:36 PM, Jun-ichiro itojun Hagino wrote:
> Fred raised concerns about DoS attack, but if you run secure OS you  
> do not have to worry about that.

Part of this relates to the concept of a "secure OS". I think the  
security experts in the room will tell you that the only truly secure  
devices is one in which no electrons are moving. One cannot actually  
say that "there is no way to successfully attack X"; one can only say  
that any such exploits are currently unknown for a system at the  
appropriate patch level and with the right configuration. That said,  
my observation was not limited to DOS attacks, although those are  
part of the discussion. My comment had to do with the integrity of  
networks people provide for themselves, and the view of the network  
as something to secure in its own right.

In my view, people in residences and in companies provide for  
themselves the things they think they need. Not everyone provides the  
same things, and not everyone views the things they provide the same  
way. For example, my wife's mother would happily give up her kitchen  
and eat out; my wife provides a kitchen in our home because she wants  
to be able to cook for herself.

In my home, I provide two wired networks and two wireless ones. One  
pair is for me (Cisco information security guidelines require my home  
office to be separate from my home), and the other pair is for my  
family. They meet at an Ethernet hub and a cable modem, the latter  
being my ISP's service demarc. My company makes similar provisions  
for itself, including 8 DMZs worldwide, an extensive internal network  
that would rival many ISPs, and interconnections with a large number  
of providers. Those networks are my and my company's property, just  
as much as the grass in my lawn covers my physical property.

Yes, the integrity of any device, physical or virtual, is in the  
final analysis its own concern, and computers need to be hardened to  
provide good computational security. A large percentage of attacks, I  
am told, come from within one's own organization. That said, it is  
also appropriate for a family or company to expect its neighbors to  
observe their property boundaries, and it is very reasonable for them  
to provide a first line of defense at those boundaries. As I said in  
the meeting, this should not preclude services that they have agreed  
should be offered in their homes or on their premises, and should not  
preclude business-to-business communications under appropriate  
governance. I will agree with Alain that a customer of an ISP should  
be able to easily let the ISP provide the services they have  
contracted, and this should be accomplished with a minimum of fuss  
and bother. But my home is not an extension of my ISP any more than  
my company is an extension of its ISPs. It is a network and there is  
a defined NNI between them. For services that the ISP has not  
contracted with me, I see no reason to allow the ISP into my home.

That's not an unfriendly statement, by the way. My neighbors come  
into my home after knocking on the door too. They are both welcome in  
my home and expected to knock.

I compare this to the defenses of the human body. One could argue  
that if every cell were robust enough, disease would be unknown, and  
in the presence of assistants like white blood cells, T-cells, and so  
on, they body has no need of a prophylactic defense. All true, and  
the fact is that those systems work pretty well. Even so, the body is  
provided with a skin - a firewall - that keeps a good percentage of  
the obvious out of it and in so doing exposes and uses those defenses  
less. I suspect that it does so both because defense in depth is a  
proven strategy and because keeping the junk out is less costly than  
curing the ills it creates.

I think the right solution is an authenticated access protocol. If  
UPnP is publicly documented, fine, if James' protocol is the best  
bet, fine, and if it is something else, so be it. But a protocol that  
allows one to identify oneself and gain admittance on authorization  
provides for the concerns that you have. Someone from within can  
access out, the governing contract being the authorization to do so,  
and on AAA confirmation access in is granted, which enables someone  
with legitimate access privileges to access what they are authorized  
to access.

Someone once said that "good fences make good neighbors". I think  
they were wise.

If in your home you want to provide open access - no doors and no  
locks - no problem. That's your policy. It's just not mine, and not  
that of very many of my customers.

---

From: Fred Baker <[email-masked]>
Date: Tue, 24 Jul 2007 10:35:52 -0500

On Jul 23, 2007, at 3:22 PM, james woodyatt wrote:

> Alas, my cellphone provider isn't particularly interested in  
> letting my phone make and receive SIP calls over my home 802.11  
> wireless network routed to the Internet.  I fear you're pointing  
> out a *feature*, not a bug.

move to T-Mobile :-)

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 25 Jul 2007 00:46:24 +0900

>as something to secure in its own right.

	"only 2 remote holes in more than 10 years" is pretty much equal to
	"there is almost no way to attack it".  in fact, the particular
	operating system i'm involved with, OpenBSD, is excluded from
	"attack this box" contests at the security-related conferenes because
	it is practically unattackable.

	enough for the ego boost :-)

>to be able to cook for herself.

	i understand the tradeoff.

	in Japan more and more kitchens avoid LPGs and use electric heaters
	due to economic issues (skyscraper apartments) and safety concerns.
	but you can never cook a good Chinese dishes with electric heaters.

>family.
(snip)

	what i've been repeatedly trying to deliver is that, (it is more of
	IAB stuff) access controls at organization borders and/or based on
	address has to stop now.
	if you wish to be sure you are communicating with murai-san you have
	to check his identity using crypto signature.
	to prevent DDoS attacks, your ISP has to react quickly, as protecting
	for DDoS in your home has no protection against your DSL/fiber links
	from being filled up.

	as far as i understand, UPnP has no authentication whatsoever (if
	there is, you would face a bootstrap problem for secret sharing).
	so, once your UPnP-client box gets hijacked, bad guys can open up any
	TCP/UDP ports in your network.  i'd rather have no UPnP on my router.
	UPnP adds more complexity onto the complexity of NAT/firewall, so what
	would you expect? :-)

itojun

---

From: Fred Baker <[email-masked]>
Date: Tue, 24 Jul 2007 11:00:52 -0500

On Jul 24, 2007, at 10:46 AM, Jun-ichiro itojun Hagino wrote:
> so, once your UPnP-client box gets hijacked, bad guys can open up  
> any TCP/UDP ports in your network.  i'd rather have no UPnP on my  
> router. UPnP adds more complexity onto the complexity of NAT/ 
> firewall, so what would you expect? :-)

To be honest, I don't know much about UPnP. What you say is  
consistent with what I have heard, and not consistent with what I  
said a few moments ago.

That doesn't make the AAA issue wrong.

> address has to stop now. if you wish to be sure you are  
> communicating with murai-san you have to check his identity using  
> crypto signature.

I understand that point. I am saying that I disagree with it. For one  
thing, the same key sharing issue applies. Basing identity on address  
is, as you say, whacked; it has to be based on something much more  
relevant. But IMHO, that is about identification and authentication.  
I am saying that authorization, which is something different, is not  
a given and should not be a given. Authorization is something I grant  
to a subset of those I encounter, and only to those that I can  
identify with some appropriate level of strength.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 25 Jul 2007 01:10:30 +0900

>That doesn't make the AAA issue wrong.

	let us hear from jhw, who should have done a lot of homework on UPnP
	matter.

>identify with some appropriate level of strength.

	i noticed you have PGP signature to ensure you identity :-)

	here i'm mixing up authentication, authorization and identification a
	little bit.  but in essense, they are all the same in the way that they
	are tied with key exchange problems.

	key distribution is a tough problem.  many people are trying hard,
	such as:
	- to make authentication optimistic when you try for the first time
	  (ssh)
	- to make keys available worldwide via DNS (opportunitistic IPsec)
	- make a hierarchy of "trust" and install root key in applications
	  (https/X509, DNSSEC)
	- use ssh/scp as a bootstrap and copy X509 keys, then exchange session
	  keys (IKE)
	some of them are deployable, some may not.

itojun

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 24 Jul 2007 19:31:19 +0300

> with legitimate access privileges to access what they are authorized

There might be a misunderstanding here. As far as I can tell, UPnP, NAT-PMP 
and ALD all allow (unauthenticated) requests coming from the inside, and 
discard any requests coming from the outside. In the physical world, most 
locks can be undone without key from the inside, and only need a key from the 
inside.

To be fair, I was told UPnP does support authentication. Only nobody uses it, 
very much like almost nobody uses authenticated DHCP. I am sure James could 
add some kind of authentication mechanism for ALD, but I doubt it would see 
much real-life use. Unless people feel it should be usable from the outside, 
much like you can open your house outside door with the appropriate key.

In any case, I think people advocating stateful firewalls on CPEs should 
really get familiar with the work done in BEHAVE wg. I am very sorry that the 
use and abuse of stateful firewalls in IPv4 world has lead to the unusability 
of just about any IETF transport protocol but UDP (Christian already hinted 
at this). If we are to require stateful firewalls for unmanaged network, we 
REALLY REALLY REALLY need to clearly explain how TCP, SCTP, DCCP and any 
other connection oriented protocol is expected to operate home-to-home. Not 
doing that would be equivalent to stating that the only valid model for 
unmanaged IPv6 is client at home and server in the server farm.

By the way, to amend James's slideset, only UDP really works with ICE (or any 
form of hole punching), while TCP works to a very-lesser extent, and 
everything else does not: DCCP, SCTP, IPsec...

My 2 cents,

-- 
Rémi Denis-Courmont

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 01:44:01 +0900 (JST)

> locks can be undone without key from the inside, and only need a key from the 

	i mentioned about the following story:
	- machines inside of your organization gets infected by viruses, trojan
	  hoses or whatever and bad guys take control of the box.
	  this can be due to poorly-mangaged laptop with VPN reachability
	  towards inside of your organization, infected laptop goes into your
	  organization after a trip to chicago, whatever.
	- bad guys plays with UPnP and punch holes on your firewall

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 24 Jul 2007 11:24:50 -0500

> by default. We need to make realistic recommendations in that context.

Hm, but another vendor, better known for other stuff, but also  
selling fine CPEs, presented a draft, and he told us that one of the  
reasons they decided to flip their default from no filtering to  
rejecting incoming sessions is that the IETF has consensus that this  
is the best approach.

Personally, I would love to see firewalls and other devices that  
think they know better what's good for me than I do die a violent  
death, but then again, there is lots of stuff out there that can't  
handle being connected to the unfiltered internet and doing exactly  
that without 5 years or so of countering "you need a firewall"  
indoctrination and replacing it with "you need to run a safe-out-of- 
the-box OS" won't do us any favors.

At this point, it looks like the best option is to have an extremely  
light-weight protocol that allows OSes (applications?) to open up  
these filters that are going to be present in default configurations  
so that only hosts that feel they're secure get unfiltered access to  
the network while other stuff is prevented from shooting itself in  
the foot.

---

From: james woodyatt <[email-masked]>
Date: Tue, 24 Jul 2007 12:25:27 -0500

On Jul 24, 2007, at 11:31, Rémi Denis-Courmont wrote:
>
> To be fair, I was told UPnP does support authentication. Only  
> nobody uses it, very much like almost nobody uses authenticated DHCP.

I have not heard that before, but it doesn't surprise me.  I do know  
that UPnP IGD is typically used without any authentication and that  
Apple's support for it in mDNSResponder assumes that the  
unauthenticated mode of operation is all that's necessary.

> I am sure James could add some kind of authentication mechanism for  
> ALD, but I doubt it would see much real-life use. Unless people  
> feel it should be usable from the outside, much like you can open  
> your house outside door with the appropriate key.

In fact, the security considerations section in my current draft  
offers the opinion that IPsec and IKE are the appropriate ways to  
secure the ALD exchange between listeners and firewalls.  I don't  
feel confident that I have adequately explored the issue, but my  
hunch is that network layer security mechanisms ought to be used for  
securing network layer control messaging.  It's possible that ALD  
needs specific signaling in Firewall Advertisements to indicate that  
listeners must have an IPsec SA to be established if they expect  
their notifications to be processed.  However, I wouldn't expect this  
feature to be necessary in most residential / small-office CPE  
deployments.

> unmanaged IPv6 is client at home and server in the server farm.

At this point, I'm beginning to believe that we are seeing the  
outlines of a very serious philosophical debate between two factions,  
most recently represented on this list by Itojun and Fred  
respectively, who have foundationally different views about the  
ethics of network security methodologies.  As a Rorty-ian neo- 
Pragmatist myself, I'm sensitive to the possibility that these two  
philosophical systems may not, in fact, have any objective principles  
in common, and that the best we might hope to do is try to get as  
much intersubjective agreement about our principles as we can muster,  
and proceed accordingly.  I believe there may be more overlap than  
most participants think.

I'm thinking about how to gather together the points where I think  
there might be some philosophical agreement.  I may have to write a  
draft.  Before I do that, I may have to spew random thoughts onto the  
mailing list and see what sticks.  Sorry about that.

Is there a tradition in IETF of writing philosophy essays as Internet  
drafts?

> everything else does not: DCCP, SCTP, IPsec...

I think I was careful to use "ICE-like" as the construction in my  
slides.  I was trying to hint at the various techniques in currency  
within the BEHAVE working group products for traversing the stateful  
filters in IPv4/NAT, e.g. TCP simultaneous open, relay services, etc.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 02:31:29 +0900 (JST)

> rejecting incoming sessions is that the IETF has consensus that this  

	i do not remember seeing IETF consensus on this matter.

> the-box OS" won't do us any favors.

	we have been telling people about it, not via IETF channel.  in short:
	- with firewalled environment morale to administer individual machines
	  go down, and they will left unpatched
	- then VPN and laptop throw in viruses and bots into organization
	  (it is from inside so firewall has no use)
	- hence you need to purchase host firewalls and anti-virus products
	- and you have to keep updating virus signature files

	if you use OS that is secure enough, you do not have to worry about
	NONE of the above.  so you got so much lower costs in operation.

	if you happened to pick OpenBSD and need some commercial support,
	of course there are: http://www.openbsd.org/support.html
	i heard Microsoft is undergoing a serious audit of Vista, i'm not
	too sure about the outcome, but i guess we can hope.
 
> the network while other stuff is prevented from shooting itself in  

	again, complexity of UPnP on top of complexity of firewall.
	remember "KISS princile"?

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 24 Jul 2007 12:20:16 -0500

> are in the network to allow traffic tagged with this through.

Long, long ago in a galaxy far, far away we tried to come up with a  
way to do scalable multihoming for IPv6. One of the approaches I came  
up with (yes, I came up with several, as did a bunch of other people,  
we had 30+ active drafts at one point) (although I think I never  
wrote a draft for this one) was:

Make middleboxes part of the architecture. Those middleboxes would  
then be able to do pretty much what shim6 does, and a lot of other  
things. One of those things would be limiting access to the outside  
world based on the application and application version. So if today  
there's a new vulnerability in your favorite browser, tomorrow that  
browser can't connect to the rest of the world but only to  
favoritebrowserupdate.com. Another feature that you get for free is  
translation between IPv4 and IPv6.

If you squint a bit you may notice that using a proxy pretty much  
gives you this in a more ad-hoc way.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 02:37:48 +0900 (JST)

> Make middleboxes part of the architecture. Those middleboxes would  

	that is called "RSIP".

itojun

---

From: Christian Huitema <[email-masked]>
Date: Tue, 24 Jul 2007 10:38:59 -0700

> 	- bad guys plays with UPnP and punch holes on your firewall

All this is an issue of tradeoffs. "Stateful firewalls" are one
particular type of trade-off. They purport to augment the security of
the system by limiting the possibility of unsolicited connection. This
is a classic way to "reduce the attack surface", and provided serious
benefits when systems would have a large number of ports open by
default. 

But the stateful firewalls block desirable applications, so applications
have to develop workarounds that in turn increase the attack surface.
Controlling the NAT with UPNP is one such workaround. STUN, ICE, Teredo
are another. Services like "go to my PC" are yet another. Today, we
cannot assess the potential security benefit of stateful firewalls
without looking at the whole system, i.e. firewalls plus traversal
mechanisms. When you take into accounts that modern systems definitely
do not leave many ports open by default, the benefit appears dubious.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 24 Jul 2007 12:41:09 -0500

On 24-jul-2007, at 10:34, Fred Baker wrote:

> bet, fine, and if it is something else, so be it.

Please note that uPnP is a death trap of a protocol, and the fact  
that it was "not invented here" shows in a bad way.

> But a protocol that allows one to identify oneself and gain  
> admittance on authorization provides for the concerns that you  
> have. Someone from within can access out, the governing contract  
> being the authorization to do so, and on AAA confirmation access in  
> is granted, which enables someone with legitimate access privileges  
> to access what they are authorized to access.

This makes a lot of sense for a corporate network, but do we really  
want to go this far for home networks? Especially since blocking  
inbound sessions _maybe_ removes 10% of the bad stuff that may happen  
to you (in IPv4, less in IPv6) while browser exploits, that don't  
need incoming sessions, are responsible for 60% or so of all security  
problems. The "creamy inside, crunchy outside" security model just  
doesn't work. If you want systems connected to a network to be  
secure, you need to go into those systems and remove or patch the  
stuff that's wide open and waiting to be compromised.

And, of course, the most insecure part of any computer is still the  
left mouse button.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 24 Jul 2007 12:52:42 -0500

> everything else does not: DCCP, SCTP, IPsec...

Why?

An important issue about the hole punching is the shape of the hole.  
If the hole has the shape of a particular transport session, you're  
not accomplishing much because you still can't receive arbitrary  
incoming sessions. If the hole is for a transport session with a  
wildcard at the remote end, you still need to understand the  
transports well enough to catch them. If the hole is IP-shaped, life  
is easy but then there are only two flavors: completely closed and  
completely open. That means only hosts that can do all their own  
filtering could safely open up a hole.

---

From: Fred Baker <[email-masked]>
Date: Tue, 24 Jul 2007 13:02:21 -0500

On Jul 24, 2007, at 11:31 AM, Rémi Denis-Courmont wrote:

> I am very sorry that the use and abuse of stateful firewalls in  
> IPv4 world has lead to the unusability of just about any IETF  
> transport protocol but UDP (Christian already hinted at this).

gee whiz. I use TCP through my stateful firewall all the time. What  
is the impediment?

---

From: Fred Baker <[email-masked]>
Date: Tue, 24 Jul 2007 13:12:06 -0500

On Jul 23, 2007, at 3:44 PM, Jun-ichiro itojun Hagino wrote:

> IP address is always locator

I would really strongly suggest that you re-read the Nimrod  
architecture:

http://www.ietf.org/rfc/rfc1992.txt
1992 The Nimrod Routing Architecture. I. Castineyra, N. Chiappa, M.
      Steenstrup. August 1996. (Format: TXT=59848 bytes) (Status:
      INFORMATIONAL)

"A locator is a string of binary digits that identifies a location in  
an internetwork.  Nodes and endpoint are assigned locators."

"An endpoint represents a user of the internetwork layer: for  
example, a transport connection. Each endpoint has at least one  
endpoint identifier (EID)."

I would agree that the current id/locator split discussion has some  
real problems; it has adopted nimrod language and hopes to acheive  
GSE results, but uses the terms to mean something different than  
Nimrod defined (as does GSE), and the result of GSE derives from the  
existence and use of equivalence classes among names, not from the id/ 
loc split.

That's another discussion :-)

http://www.ietf.org/rfc/rfc1753.txt
1753 IPng Technical Requirements Of the Nimrod Routing and Addressing
      Architecture. N. Chiappa. December 1994. (Format: TXT=46586 bytes)
      (Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc2102.txt
2102 Multicast Support for Nimrod : Requirements and Solution
      Approaches. R. Ramanathan. February 1997. (Format: TXT=50963  
bytes)
      (Status: INFORMATIONAL)

http://www.ietf.org/rfc/rfc2103.txt
2103 Mobility Support for Nimrod : Challenges and Solution Approaches.
      R. Ramanathan. February 1997. (Format: TXT=41352 bytes) (Status:
      INFORMATIONAL)

---

From: Fred Baker <[email-masked]>
Date: Tue, 24 Jul 2007 13:15:07 -0500

> And, of course, the most insecure part of any computer is still the  

not so! it's the idiot attached to it...

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 24 Jul 2007 13:17:00 -0500

> 	remember "KISS princile"?

That may very well be, but if you have a firewall and/or NAT device,  
NOT having something that can punch holes means you pretty much never  
get to talk to anyone else in the same situation, so no peer to peer  
applications, IM, voice/video chat... So either kill the firewall or  
live with the complexity.

Iljitsch

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 03:18:10 +0900 (JST)

> live with the complexity.

	as i mentioned before, i do not have any kind of firewall in my home.

itojun@eat your own dog food

---

From: james woodyatt <[email-masked]>
Date: Tue, 24 Jul 2007 13:20:10 -0500

On Jul 24, 2007, at 11:24, Iljitsch van Beijnum wrote:
>
> At this point, it looks like the best option is to have an  
> extremely light-weight protocol that allows OSes (applications?) to  
> open up these filters that are going to be present in default  
> configurations so that only hosts that feel they're secure get  
> unfiltered access to the network while other stuff is prevented  
> from shooting itself in the foot.

The obvious rebuttal (which, in my mind, always comes with a middle- 
class English accent from my having heard something like it over and  
over again from Stuart Cheshire) is this:

	Devices that aren't secure enough for unfiltered access to
	and from the public Internet SHOULD NOT be accepting router
	advertisements for globally reachable IPv6 prefixes.

	Sheltering them with stateful packet filters at network
	gateways removes the incentive for their engineers to
	consider network security with an appropriate level of
	seriousness, which leads to more problems than the packet
	filters are intended to (or capable of) solving.

	We made this mistake with IPv4 for reasons that make sense
	only in their historical context.  There is no reason to
	insist on making this mistake again with IPv6.

This is hinting toward the philosophical matters I think underlie  
this debate.  I'm working on a more polished argument for striking an  
acceptable compromise.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jul 2007 20:35:08 +0200

> 	i do not remember seeing IETF consensus on this matter.

In fact RFC 4864 is an informational document that does not
use RFC 2119 keywords, and its scope is very clear (see
the Abstract): a description of how a site can obtain the
claimed benefits of NAT without using a NAT. Among other things,
iff you want stateful firewalling, RFC 4864 shows that you don't
need a NAT to obtain it.

That is orthogonal to the question of whether stateful firewalling
is a good thing.

I think we should write the CPE document in the same spirit - if
you want a stateful firewall in your CPE, here is what it should do.
(And I have no doubt we can learn from BEHAVE.)

     Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 24 Jul 2007 13:41:05 -0500

> 	as i mentioned before, i do not have any kind of firewall in my home.

Neither do I (and there doesn't seem to be one between the IETF  
network and the rest of the world, either) but that's not really the  
point, apparently, we now have consensus that a firewall is needed  
for residential use but these people want to do peer-to-peer and run  
servers so we need the hole punching.

If you can formulate an argument powerful enough to convince the rest  
of the world that firewalls aren't needed, this would be the moment  
to do it...

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1338

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 24 Jul 2007 21:41:16 +0300

On Tuesday 24 July 2007 20:52:42 Iljitsch van Beijnum wrote:
> incoming sessions.

Yes, that still sucks. But if you have BEHAVE-TCP support, you can at least do 
TCP simultaneous open (forget about DCCP and SCTP though), provided you have 
an out-of-band signaling mechanism.

Without BEHAVE-TCP, you cannot do home-to-home at all, and you have to invent 
your own crappy[1] protocol on top of UDP.

[1] At least, *I* am not capable of reinventing something nearly as good as 
TCP or DCCP by myself.
-- 
Rémi Denis-Courmont

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 24 Jul 2007 13:48:06 -0500

> your own crappy[1] protocol on top of UDP.

Note that currently deployed NAT-PMP (Apple) and UPnP (the rest of  
the world) forward all incoming sessions from the outside world  
towards a specific port number towards the host that registered that  
port number using NAT-PMP/UPnP, so the host in question gets to act  
as a regular server (well, there's still NAT), no need for  
simultaneous open or UDP tricks.

---

From: Mark Smith <[email-masked]>
Date: Wed, 25 Jul 2007 07:31:24 +0930

> 	any comments from ericsson? :-)

These Nokia models caused a bit of a buying spree where I work (a
smaller SP), with one of the main reasons being the Wifi/SIP
capabilities. The MD (one of the owners) has made his Wifi key at home
the same as the one in his area of the office, so moving between those
Wifi points is seemless for VoIP. Fortunately the organisation has
followed a host based firewall and application based authentication
model, so doing this isn't as much of a problem as if they'd followed
the hard shell, gooey centre firewall model.

I also found it a bit interesting that the host based firewalling /
application authentication model had been followed without it seeming
to be much of a conscious decision by the people who where there before
I started. Possibly because as the host/application based tools were
available when it was necessary to implement host/applicatiion
security, it then inherently became the obvious and better way to do it.

Assuming an appropriate level of security measures (e.g. matching Wifi
keys), being able to move between home and work networks easily with
something such as a Wifi/SIP enabled cell/mobile phone is something
that I think is important that we don't inhibit with any recommended
implementation models on CPE and stateful firewalls.

Regards,
Mark.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 07:15:18 +0900 (JST)

> http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1338

	nah, again, illusion of security based on blocking traffic...

	i can help people secure their OS in a serious manner.
	especially those which are based on BSD IPv4/v6.
	hello Steve! (no, not Deering, i'm waiting for Jobs)

	http://www.openbsd.org/papers/asiabsdcon07-network_randomness/
	http://www.openbsd.org/papers/ven05-deraadt/

itojun

---

From: Mark Smith <[email-masked]>
Date: Fri, 27 Jul 2007 08:32:44 +0930

On Tue, 24 Jul 2007 13:20:10 -0500

> this debate.  I'm working on a more polished argument for striking an  

(You might imagine me saying this with my Australian accent) I agree
with this completely, except that I don't think we can even assume that
the domain where ULAs might be assigned is secure and trustworthy
enough these days. I think commodity Wifi in residences has probably
put an end to that assumption being mostly true, as it was in the past
with wired infrastructure. 

If we're focusing implementing security at layer 3 and above, what
assumptions are we making about the security of layer 2, and are they
appropriate assumptions to be making?

Assuming Wifi is probably going to be, if it isn't already, the most
popular way of creating a network inside a residence, does anybody know
of any citable formal studies measuring how well Wifi security has been
configured in residential areas ?

Crikey! He almost got me that time! That would have stung a bit!

Regards,
Mark.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 26 Jul 2007 18:24:07 -0500

> configured in residential areas ?

I'm amazed by the number of wifi networks I see whenever I open my  
laptop here in Chicago. However, (not specifically about Chicago) the  
number of _open_ wifi networks seems to be lower than a few years  
ago. And we now have WPA2 which is pretty strong, so things seem to  
be going as well as we could hope.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Jul 2007 14:43:19 +0200

> with wired infrastructure. 

<accent cc="GB">
I think anyone who imagines ULAs have any security value
whatever has been smoking funny vegetables.
</accent>

    Brian

---

From: Gert Doering <[email-masked]>
Date: Fri, 27 Jul 2007 20:01:32 +0200

Hi,

> gee whiz. I use TCP through my stateful firewall all the time. What  

Incoming connections?

This has been said before: if all the world is "clients behind firewalls
connecting to servers in datacenters", IPv6 has failed its mission to 
restore end-to-end connectivity.

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

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: Fred Baker <[email-masked]>
Date: Fri, 27 Jul 2007 19:44:09 -0700

we seem to be talking past each other. I have a very strong feeling  
that some of us are not listening, or deliberately misunderstanding.  
I'll refer you to my note of 24 July 8:34 AM PDT; this one builds on  
that.

The objective of IPv6 is to restore the end to end addressing  
architecture. I believe that it does that, if we don't install  
network address translation and in so doing jinx that.

Alain's comment in the plenary Thursday evening that James document  
and my comments on this list advocate NAT are, in the best possible  
case, incorrect - nobody is talking about NAT in IPv6, although I do  
believe that there will be places that network operators choose to  
use that class of capability. In the worst case, it constitutes a  
deliberate misstatement calculated to cause confusion and troll for a  
flame war in this venue. I choose to believe the former, although I  
ask myself the question.

Alain's comment in the v6ops meeting Monday afternoon is patently  
disingenuous, however. His assertion was that there should be no  
protection of the capacity in a home because he wants to offer  
services in the home. Well, if the network is one of his subscribers,  
he already has a trojan in the network - the set-top box. It will  
manage all of the services he offers, and for a significant subset of  
them will be the chassis from which his service is offered. That set- 
top box will be configured by him and installed (often by his  
subscriber) in the subscriber network. It will connect to equipment  
in his network and offer those services. So traversal of a stateful  
firewall (my canonical example of which is a Cisco CBAC firewall,  
google for it) is in his case an absolutely done deal.

Now let me make an observation. RFC 4193 describes "Unique Local IPv6  
Unicast Addresses". They, and their predecessors, Site-local  
Addresses, were defined because there is a recognized need in  
networks - there are systems for which there is no legitimate reason  
that a system in a different network would ever communicate with it  
other than directly using a link-local address. Obvious examples  
include routers and other network equipment; such systems also  
include servers that are intended to be private to the company. There  
is a move right now to centrally assign prefixes for unique local  
addresses to administrations, the reason being to ensure that  
neighboring networks do not in fact accidentally choose the same  
prefix and so expose themselves to each other. So we as a community  
have agreed that not all hosts should be reachable by other hosts.  
This provides a routing solution to a basic issue addressed by common  
firewalls - hiding systems from each other and making it impossible  
for them to communicate.

Question: under what circumstances would my upstream provider enable  
me to access systems in his network? I can think of three potential  
reasons:
- for me to be able to send datagrams using my upstream router
- for me to access servers and services in his network that I have
   contracted for access to
- for my network to exchange information with the upstream network;
   routing, network management, and so on

I suspect that any other system will be completely inaccessible to  
me. The reason is essentially that I have no need to know and no  
legitimate reason to access it.

So, question: what is the argument that I must open all of my systems  
to him? If I am multihomed, what argument says that this must be  
observable by one of those upstream networks, or that my use of  
competing services need be visible to him? Alain wants to offer  
services in my home; what if I don't want them? How do I know that  
the services he is deploying are benign to me? Lawful Intercept is a  
service...

If I have contracted services from Alain's company, why would I not  
make it possible to use those services?

Now, let's talk a little about how a stateful firewall (which is  
different than a NAT) works. The internal implementations vary, but  
in the simplest case a stateful firewall is a network-layer-only  
device. It has an "inside" and an "outside". On the "inside"  
interface, any new session perceived outbound results in a dynamic  
access list entry permitting responses to its messages to enter the  
network on the "outside" interface. On the "outside" interface, there  
are essentially three sets of rules:

  - traffic responding to datagrams from "inside" is permitted
  - other traffic that has been pre-authorized is permitted
    example: an ACL rule permitting SMTP traffic to go to an internal  
mail server
  - everything else is denied

What is the reason for that? To prevent misuse of the capacity in the  
network. Yes, it is often seen as a protection of the host, but the  
sense in which that is actually true is limited. Most attacks happen  
from behind the firewall, and in any event there are ways to subvert  
such defenses by having a trojan access outbound.

Now, Remi (I believe) observed that address-based rules like "let  
mail traffic go to my mail MTA" are a bit dated. OK, no problem. That  
said, one of the most effective spam filters in use today is based on  
a simple reputation service - one allows mail from one's business  
partners to get to one's secondary spam trap, but traffic from bots  
(whose addresses are determined and distributed by some form of  
reputation service) are in effect null routed. The SYN never gets to  
the secondary spam trap, the SYN ACK never gets back, a RST kills the  
session, or maybe the EHLO is responded to with an appropriate error  
message. Bottom line, a very high percentage of spam email simply  
never leaves the bot. No prophylactic protection on one's network?  
Well, I guess we'd better rethink our spam filters. SpamAssasin and  
its cousins are excellent secondary spam filters, but at least at my  
company refusing the SYN from a bot is orders of magnitude less  
costly and more effective.

We also discussed the use of firewall traversal protocols like UPnP.  
I profess no knowledge of the particulars of any of them, but in  
concept they are pretty straightforward. Given a global address  
space, if I want an application to have access to the systems in my  
home and trust it to not misuse the capacity I have provided, I have  
two choices. I can go to each system and configure it accordingly, or  
if I have a prophylactic I can program the firewall. In reality, I  
probably do both. I configure the firewall with some appropriate  
credential and give that credential to the peer I want to grant  
access to, and now anyone that has that credential can get added to  
my "came from inside" dynamic rule or to the list of pre-authorized  
sessions. If one does that, sessions initiated from outside are  
pretty straightforward.

Lets make one thing real clear. It is abundantly clear to the vendors  
in the room that there is a market for IPv6 CPEs with firewalls.  
Technology religion to the contrary isn't going to stop that. So  
shouting at the top of your lungs that "we don't like firewalls" is  
in essence pissing into the wind. Save your breath. The products are  
going to be built and deployed. It is equally clear that there is a  
set of people who don't want to deploy a firewall. More power to them  
- the firewall capability needs to be optional, either by product  
feature set or by configuration. The market they represent will  
dictate either that there will be routers without firewall features  
or that ones with firewalls features can be usefully deployed without  
them. vedors will respond to them as well.

We need to not be silly enough to think that one size fits all. If  
the service providers can hide their network elements, homes need to  
be able to do the same thing, and for the same reason.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 27 Jul 2007 23:21:10 -0700

> in the room that there is a market for IPv6 CPEs with firewalls.

The market is based on supposed customer demand. Customer demand
evolves. You cite an obvious benefit, "hide my home network from my
ISP". But there is an equivalent cost, "prevent Skype from working
well". Or Bit Torrent, or whatever peer to peer application happens to
be popular. 

The choice is really between host firewalls and CPE firewalls. Both
achieve the "isolation" goal. The big difference is that host firewalls
can be controlled by a local API, while controlling a CPE is much
harder. If the host has adequate protection, then the intermediate
firewall in the CPE increases the overall cost without adding any
significant value.

> going to be built and deployed. 

You are making the pessimist argument: since the worse is unavoidable,
it would be best to stop whining and just deal with it. Application
developers are actually used to that approach -- develop for the network
you have, and route around the damage inflicted by half-brained boxes.
Most likely, they will develop "automatic firewall traversal"
strategies. In a peer to peer network, for example, they will probably
invent a "pre-SYN" message that is relayed through a third party, so
that the two peers send their SYN packets simultaneously and effectively
defeat stateful packet inspection. Or, maybe, they will achieve the same
result using IPSEC. Or they will use a transport over UDP. Welcome to
the arms race.

-- Christian Huitema

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2007 11:30:40 -0700

[ Added BEHAVE working group. ]

On Jul 27, 2007, at 19:44, Fred Baker wrote:
>
> [...] Alain's comment in the plenary Thursday evening that James  
> document and my comments on this list advocate NAT are, in the best  
> possible case, incorrect - nobody is talking about NAT in IPv6,  
> although I do believe that there will be places that network  
> operators choose to use that class of capability. In the worst  
> case, it constitutes a deliberate misstatement calculated to cause  
> confusion and troll for a flame war in this venue. I choose to  
> believe the former, although I ask myself the question. [...]

I wasn't present for the plenary, so I don't know what M. Durand  
said, but let me clarify my position, which I believe is best  
characterized as a "warning that we have not quite succeeded in  
making NAT obsolete" with IPv6.

The need to implement what I am now calling "application transparency  
helpers," which function like ALG modules in an IPv4/NAT firewall,  
but which only help control transport filtering state in response to  
application protocol content without actually coordinating any UNSAF  
function like an ALG does, is a vector by which NAT implementations  
may worm their way back into the IPv6 architecture.

I'm currently looking at source code in OpenBSD PF that appears  
designed to use IPv6-NAT to redirect application flows to userland  
proxies for exactly this purpose.  IPv6 support for an FTP  
"transparency helper" is on my list of things I expect to need, and  
using an IPv6 NAT to redirect FTP control flows in and out of my  
existing IPv4 FTP proxy looks like the obvious shortest path to  
working code.  (Similar things will need to be done with all the  
other major application protocols.)

If IPv6 NAT were truly obsolete, this wouldn't be the case, but it  
is.  Hence, my warning.

Coming away from IETF 69 in Chicago, I'm now convinced that IETF will  
not be revisiting its consensus that the public IPv6 internet is  
intended to be clients behind multiple layers of firewalls  
communicating mainly through mediation services in data centers.  I'm  
certain my employers will have no trouble adapting to this reality.

I'm no longer certain that IPv6 will ever be a suitable replacement  
for IPv4/NAT in residential settings, but I see reasons to be hopeful  
that all is not lost on that account.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jul 2007 12:15:11 -0700

> -----Original Message-----
> From: james woodyatt [mailto:[email-masked]] 
> Sent: Monday, July 30, 2007 11:31 AM
> To: IPv6 Operations; Behave WG
> Subject: [BEHAVE] Re: CPE equipments and stateful filters
...
> other major application protocols.)

Application-aware ALGs are bad.

Passive-mode FTP (using the "PASV" verb) has been supported on 
all modern FTP clients and FTP servers for a long time (going on a 
decade for most FTP clients and FTP servers).  Passive-mode FTP 
causes the TCP data connection to be initiated by the FTP client (as 
is the TCP control connection), which eliminates the need for any ALG 
or ALG-like function in NATs and in firewalls.  Is there a reason 
passive FTP can't simply be mandated for v6, so we can avoid FTP-aware
ALGs?

> communicating mainly through mediation services in data 
> centers.  I'm certain my employers will have no trouble 
> adapting to this reality.
>
> for IPv4/NAT in residential settings, but I see reasons to be 
> hopeful that all is not lost on that account.

I do hope you pursue a BoF in Vancouver to discuss the need for 
endpoints to communicate to firewalls in IPv6.

-d

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 30 Jul 2007 22:17:49 +0300

> other major application protocols.)

As far as I know, EPSV is recommended against EPRT, so I fail to see a 
problem for that *particular* protocol. I understand many legacy FTP 
clients use PORT by default, but these cannot do IPv6 anyway.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Gert Doering <[email-masked]>
Date: Mon, 30 Jul 2007 21:33:04 +0200

Hi,

> passive FTP can't simply be mandated for v6, so we can avoid FTP-aware

Correct me if I'm wrong - but you'll need "firewall support" for 
PASV / EPSV ftp as well, just on the other side of the connection.

If you run your server behind a firewall (which is a pretty common thing
to do), and want to offer FTP services, the firewall needs to know which
port to open for PASV connections.

Gert Doering
        -- NetMaster

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2007 12:51:23 -0700

> Application-aware ALGs are bad.

They are better than nothing.

> passive FTP can't simply be mandated for v6, so we can avoid FTP-aware

No.  Passive-mode FTP is broken for exterior clients connecting to  
interior servers by stateful packet filters.  Merely allowing the FTP  
control port through the filter to the interior server is  
insufficient.  Requiring FTP clients and servers to use TCP  
simultaneous open for data connections could address this problem,  
but I've been using FTP as an example to illustrate the wider problem  
with applications in general.

We still have an open problem regarding IKE and IPsec ESP/AH, and I  
don't see a comparable way to resolve it without an application  
transparency helper or by allowing inbound ESP/AH by default.   It  
remains to be seen whether consensus will emerge around the latter  
solution, so I contend the former remains an open problem.

There are similar issues with RTSP and RTCP/RTP flows.  And other  
existing application protocols.  Not to mention applications not  
imagined by their developers yet.  And and and.  So long as the IPv6  
architecture is defined such that communications between endpoints  
are always expected to originate with nodes behind firewalls and  
mediated by services in data centers, we will be saddled with the  
need for either 1) application transparency helpers inside network  
firewalls, and/or 2) an improvement to the core IPv6 specifications  
along the lines of my Application Listener Discovery (ALD) proposal.

> endpoints to communicate to firewalls in IPv6.

I'm working on socializing that plan with my management.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 30 Jul 2007 23:30:05 +0300

Le lundi 30 juillet 2007, james woodyatt a écrit :
> So long as the IPv6

I would not that the architecture is defined such. First, because the 
IETF, as an SDO, has an history of NOT specifying architectures. 
Second, because there is clearly NOT a consensus on that topic.

*But*, I would agree that, in any case,
- whatever the IETF mandates, recommends, suggests, or not,
- whether or not this is a good idea,
- whether or not it abides to the IETF design principles,
- whether ir not this is good engineering,
- whether it displeases some consumer ISPs,
- whether it breaks IETF transport protocols,
- whether it breaks IETF mobility protocols [1],
- whether or not it makes IPv6 rather useless compared to IPv4+NATs,
- ...

...there will be stateful firewalling middleboxes in some "unmanaged" 
network cases. And it will also definitely happen on consumer-grade 
radio links.

--- Footnote: ---
[1] Mobile IPv6 has been notoriously absent from this debate so far. It 
is all the weirder as it has been at the center of another recent IETF 
IPv6 hot topic: RH0 deprecation.
---

Therefore, as an individual, I think there would be value for IETF in:

- working on ALD or something along its line,

and,

- working on BEHAVE-ish recommendations for such boxes, to minimize the 
damage to the works of the IETF Transport and Internet areas (and 
indirectly the RAI and Apps areas). By this, I mean non-UDP transport 
protocols, mobility/multihoming stuff, and some future proofing.

My 2 cents,

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jul 2007 13:33:47 -0700

> From: Gert Doering [mailto:[email-masked]] 
> Sent: Monday, July 30, 2007 12:33 PM
> To: Dan Wing
> Cc: 'james woodyatt'; 'IPv6 Operations'; 'Behave WG'
> Subject: Re: [BEHAVE] Re: CPE equipments and stateful filters
> 
> Hi,
> 
> > passive FTP can't simply be mandated for v6, so we can 
> > avoid FTP-aware ALGs?
> 
> to do), and want to offer FTP services, the firewall needs to 
> know which port to open for PASV connections.

You are certainly right that such a firewall protecting the 
FTP server needs to open pinholes for the incoming TCP data 
connection when using PASV.

(We could argue about the commonality of such a configuration,
but there isn't much point in such an argument; the need 
for hosts to communicate the desire for incoming connections
to the firewall is what's important.)

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jul 2007 15:47:34 -0700

> insufficient. 

You're right.  Thanks for pointing out my mistake in assuming
the FTP server wouldn't, itself, be behind a similar firewall.

> Requiring FTP clients and servers to use TCP  
> but I've been using FTP as an example to illustrate the wider 
> problem with applications in general.
> 

I don't see why you'd allow unsolicited ESP or AH, but deny other
protocols (ICMP, UDP, TCP, SCTP, DCCP).  It seems we need to solve
this problem for all protocols.  Certainly, if one is considering
a battery-powered host, where receiving any packet will wake up
the radio and host processor, unsolicited IPsec packets shouldn't 
be allowed any more so than unsolicited UDP or TCP.

> There are similar issues with RTSP

RTSP control traffic over TCP?

> and RTCP/RTP flows. 

At this point, ICE (draft-ietf-mmusic-ice) is believed to provide
a viable, incrementally deployable mechanism for IPv4 and IPv6, 
including if you're behind a NAT or firewall if that NAT or firewall
allows packets from inside->outside to create permissions for 
outside->inside; most NATs available to consumers work like that
and all firewalls can be configured like that.

> And other  

I see ALD being helpful for both the case of talking to a well-
known server in a datacenter, and also being helpful for peer-to-
peer applications, such as running an FTP client when you're behind
a firewall trying to communicate with an FTP server that is also behind
a firewall.

> I'm working on socializing that plan with my management.

Good deal.

-d

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2007 16:31:43 -0700

On Jul 30, 2007, at 15:47, Dan Wing wrote:
> [I wrote:]

Yes.  As seen in QuickTime and RealPlayer applications.

> and all firewalls can be configured like that.

Existing code (which does support IPv6) has no support for ICE.

Even in the event ICE isn't deployed, how do you recommend I resist  
the inevitable pressure to implement an application transparency  
helper for these A/V streaming applications?  I'm still having to  
maintain ALG's in IPv4/NAT for various VPN protocols even though we  
have long had standards track protocols for IPsec encapsulated in UDP  
and negotiating NAT traversal of IKE.

I'm expecting to have to implement a helper for IKE and IPsec ESP/AH  
in IPv6.  Without it, I expect route optimization in Mobile IPv6 to  
be broken, since mobile nodes are supposed to bind with their home  
agents using an IPsec ESP security association.  In fact, the more I  
read about route optimization in MIPv6, the more convinced I am that  
it represents the most glaring illustration yet of our failure to  
consider properly the implications of recommending the widespread  
deployment of stateful middlebox packet filtering in IPv6 networks.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jul 2007 17:28:02 -0700

> helper for these A/V streaming applications? 

With ICE, such application helpers are not necessary.  This was one
of the major design decisions in ICE.  This is the same design 
descision that allows Skype to "work anywhere".  

> I'm still having to  
> have long had standards track protocols for IPsec 
> encapsulated in UDP and negotiating NAT traversal of IKE.

The only IPsec client implementation I'm aware of is Cisco's, and
I know our implementation does not provide automatic detection or
fallback from IPsec-over-IP to IPsec-over-UDP; rather, the user has
to select this themselves or be artificially limited to always use
UDP.  IPsec-over-UDP is, of course, less bandwidth efficient than
IPsec-over-IP.

It's important to have such automatic fallback mechanisms.  ICE
provides these automatic fallbacks by using connectivity checks.

We know how to multiplex those connectivity checks with RTP/RTCP, 
DTLS, TLS, HIP, and SIP.  I expect ICE connectivity checks could
be multiplexed with many other protocols.  I am not suggesting ICE
is the ideal solution for a host to tell its v6 firewall that it
desires incoming traffic -- I am just explaining how ICE works 
as a datapoint.  You may find it valuable to read the first 
two sections of ICE (and ignore the detail).  Also, Jonathan 
Rosenberg gave an ICE tutorial in Chicago, posted at 
http://www.jdrosen.net/papers/ice-ietf-tutorial2.ppt.  Like you,
I wasn't present at the Thursday technical plenary but I listened
to the audio,
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch5-thurs-
afnoon-plenary.mp3

> deployment of stateful middlebox packet filtering in IPv6 networks.

http://tools.ietf.org/html/draft-tschofenig-mip6-ice-01 describes 
how ICE might be useful for Mobile IPv6.

-d

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2007 17:56:08 -0700

On Jul 30, 2007, at 17:28, Dan Wing wrote:
>
> <http://tools.ietf.org/html/draft-tschofenig-mip6-ice> describes  

I'm reading this draft now.

It's fascinating.  The authors apparently assume the deployment of  
IPv6 NAT.  I wonder why.

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2007 19:01:33 -0700

> I'm reading this draft now.

If I understand how this might work, it would involve encapsulating  
IPsec ESP and IKE in UDP, to transit firewalls between MN's and their  
HA's, using conventional UDP state tracking.

We don't currently have any protocol whereby IKE decides to switch  
over to UDP encapsulation, except in the NAT-traversal case, do we?   
With IPv6, we still think we have no NAT, so tests for reflexive  
addresses to match IKE initiations will always succeed.

What triggers the switch to UDP encapsulation?  The mobility layer  
trying to do STUN connectivity tests on the ESP protocol?  Blech, but  
I guess it works most of the time.  If it fails mysteriously, just  
try again-- that seems to be a common failure recovery method in  
human-centered systems.  I can't say I approve of it.  For one thing,  
I really don't like the idea of extending my implementations of IPsec  
and IKE to do STUN over protocol=50 and port=udp/500.

RFC 4487 describes additional issues, e.g. CN's reaching MN's that  
roam behind networks with firewalls.  <http://tools.ietf.org/html/ 
draft-bajko-mip6-rrtfw> proposes a way to work around the RRT issue,  
which looks on its face to be an ugly but workable hack.  It reminds  
me that <draft-ietf-v6ops-cpe-simple-security> needs to be very  
explicit about how to handle the mobility extension header.

Finally, <http://tools.ietf.org/html/draft-tschofenig-mip6-ice> seems  
not to care at all about the problem of home agents behind  
firewalls.  RFC 4487 raises that issue, but I'm not seeing how M-ICE  
is supposed to address it.  Did I miss something?

My head hurts trying to sort out all the questions I have about ways  
these approaches potentially might fail during incremental  
deployment.  On the other hand, all this stuff seems a lot simpler--  
though still pretty soul-killingly fragile-- with ALD in the mix.  I  
still think we'd be better off without any SPF middleboxes.  (Oh, by  
the way, I remember now why I'm not optimistic about firewalls  
helping keep denial-of-service traffic off first mile links.  That's  
a topic for another message, though.)

---

From: Gert Doering <[email-masked]>
Date: Tue, 31 Jul 2007 08:27:12 +0200

Hi,

> UDP.  IPsec-over-UDP is, of course, less bandwidth efficient than

This is again assuming "the IPSEC session is initiated outbound-only,
and the IPSEC server (gateway, whatever) is in a corporate data center".

In an end-to-end world, it may be desirable to have one residential
user setup IPSEC to another residential user.  Both behind such stateful
firewalls that neither permit unsolicited inbound UDP.

Gert Doering
        -- NetMaster

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jul 2007 23:43:03 -0700

> user setup IPSEC to another residential user.  Both behind 
> such stateful firewalls that neither permit unsolicited 
> inbound UDP.

In such a case, they need to communicate each others IP addresses
(and perhaps UDP ports) using a rendezvous protocol (such as SIP,
see draft-saito-mmusic-sdp-ike-01.txt) in order to allow one (or both)
to allow inbound UDP (or 'raw' IPsec), or the server would need to 
tell its firewall to permit unsolicited incoming traffic.

-d

---

From: Gert Doering <[email-masked]>
Date: Tue, 31 Jul 2007 08:58:22 +0200

Hi,

> tell its firewall to permit unsolicited incoming traffic.

Which seems to be the point of this discussion.  "If we are going to 
have stateful firewalls, due to popular belief that this is a good thing, 
how to tell the firewall that it should stop disturbing traffic".

Gert Doering
        -- NetMaster

---

From: james woodyatt <[email-masked]>
Date: Tue, 31 Jul 2007 10:19:52 -0700

On Jul 30, 2007, at 23:43, Dan Wing wrote:
>
> ...or the server would need to tell its firewall to permit  
> unsolicited incoming traffic.

It would be more accurate to describe that method like this: the  
server would need to solicit the firewall to permit 1) inbound IKE  
initiations from arbitrary remote addresses, and 2) IPsec ESP/AH  
flows for negotiated security associations.  Neither of these two  
forms of traffic could reasonably be described as "unsolicited" in  
this case.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Jul 2007 10:46:37 -0700

> flows for negotiated security associations. 

Agreed.

> Neither of these two  

We have different definitions of 'solicited traffic' and 
'unsolicited traffic'.  Other than opening a listener on UDP/500 
for IKE (and telling the upstream firewall to please open a 
permission for incoming traffic), the host didn't do anything to
solicit an incoming IKE packet.  I call that incoming traffic
'unsolicited', because the host (and its firewall) are unaware
of when a client will send a packet to establish a connection.
An HTTP server or SMTP server fall into this category, for 
example.

This differs from the SIP model and the RTSP 2.0 model.  In
both SIP and RTSP 2.0, an offer/answer exchange allows the 
server to learn the client desires a new session.  With that
knowledge, the server can communicate more specific information
to its firewall about the client's IP address; in this way, the
firewall doens't need to necessarily permit incoming IKE packets
from arbitrary remote addresses, unless those are first signaled
with SIP or RTSP.  This model is also used by HIP and EME, two
working groups in the IRTF (www.irtf.org).  This is what I would
consider 'solicited traffic'.

What are your definitions?

-d

---

From: james woodyatt <[email-masked]>
Date: Tue, 31 Jul 2007 12:08:21 -0700

On Jul 31, 2007, at 10:46, Dan Wing wrote:
> [ I wrote: ]
>> Neither of these two forms of traffic could reasonably be  
>> described as "unsolicited" in this case.
>
> 'unsolicited traffic'.

That seems to be the case.

> What are your definitions?

I have a more human-centered view of what it means for traffic to be  
solicited: if a human network administrator is expecting the traffic,  
then any protocol or method initiated by an administrator for the  
purpose of enabling an exception to the "denial by default" policy is  
an explicit solicitation.

For example, an HTTP or SMTP server could solicit inbound connections  
by sending an NSLP CREATE/EXT message to the appropriate NSIS  
responder.  A more common scenario might be the case where an Apple  
File Sharing (AFP) protocol server advertises a DNS-SD record with  
wide-area Bonjour™ and opens an IPv4/NAT translation for it with NAT- 
PMP.

---

From: [email-masked]
Date: Tue, 31 Jul 2007 15:40:53 -0400

YES!  Definitions are very important here, or we'll wind up talking in 
circles. 

> ... We have different definitions of 'solicited traffic' and 
> 'unsolicited traffic'. ...

Interesting observations Dan.  The differences are around what prior 
knowledge is available.  I think it can be generalized and expanded. 
(Whipping out my handy dictionary.) 

> I call that incoming traffic [intentionally listened for]
> of when [or from where] a client will send a packet to establish 
> a connection.

"Unsolicited" does seem to be a good term for this category.  Perhaps 
"Expected" would be a good characterization also. 

> ... [some protocol] exchange allows the 
> to its firewall about the client's IP address [and timing 
> of the required pihole]; ...  This is what I would

Yup, "Solicited".  "Negotiated" or "Signalled" might also be appropriate 
terms.    Note also, the actual signalling, leading up to the Solicited 
traffic, may well have been some other category. 

I would add: 

"Unexpected / unwanted" -- traffic which was not explicitly indicated as 
ready to receive, either by listening at the server and (potentially) 
opening the corresponding pinhole in the firewall (either of Unsolicited 
or Solicited above), or by client initiation (next).   This is the "bad 
stuff" that should be dropped on the floor. 

"(Client) Initiated" -- traffic that started from the "inside", by the 
client. 

Just typing out loud... 

-- Peter Blatherwick

"Dan Wing" <[email-masked]>
Sent by: [email-masked]
31.07.07 13:46
 
        To:     "'james woodyatt'" <[email-masked]>, "'IPv6 Operations'" 
<[email-masked]>, "'Behave WG'" <[email-masked]>
        cc: 
        Subject:        RE: [BEHAVE] Re: CPE equipments and stateful 
filters

Agreed.

-d

---

From: Christian Huitema <[email-masked]>
Date: Tue, 31 Jul 2007 18:01:44 -0700

> An HTTP server or SMTP server fall into this category, for

It makes a ton of sense to just leave the IKE port (UDP 500) open. IKE
is a fairly robust protocol, with built in protection against DOS. It is
part of the security suite, and thus the software implementations tend
to be scrutinized and well tested. At the end of the IKE exchange, the
parties have identified each other, and have made a conscious decision
to authorize the communication. Clearly, the follow on traffic may be
"unsolicited", but it will not come from random parties. Leaving port
500 open looks like good engineering!

-- Christian Huitema

---

From: james woodyatt <[email-masked]>
Date: Tue, 31 Jul 2007 20:01:49 -0700

On Jul 31, 2007, at 18:01, Christian Huitema wrote:
>
> It makes a ton of sense to just leave the IKE port (UDP 500) open.

I agree.  I think <draft-ietf-v6ops-cpe-simple-security> says to do  
this.  If it doesn't, then the next revision (coming soon) will say it.

The argument against doing this, which I've heard at least one WG  
Chairman offer me, is that leaving any port or protocol open to all  
inbound traffic exposes the interior network to denial of bandwidth  
attacks (along with potentially draining the batteries of portables  
in power-save mode).

The more I've thought about that problem, the more I've come to  
believe that using stateful filtering middleboxes to counter the  
threat is like responding to the possibility of your house eventually  
being attacked by a swarm of mosquitos by always keeping your living  
room filled with carbon monoxide.  Yes, you've prevented the  
mosquitos, but you've also denied yourself access to your living room.

The traditional way you control mosquito populations is with taxpayer- 
funded pest control services going through the neighborhood, spraying  
insecticide into all the standing water collectors to keep them from  
breeding.  Something similar to that, I think, is the proper way to  
engineer an Internet pest control program.

If I ruled the world with an iron fist, operating a zombie-- even  
unknowingly-- would get your IP dial-tone terminated at your  
demarcation point, and you'd have to submit to an audit to get it  
turned back on again.  Carriers who didn't do this would see their  
peering jeopardized, then degraded, and finally dumped, with their  
contracts thrown into liquidated damages.  Failure to police your  
peering points would be grounds for operators in the DFZ to apply  
filters, limiters and/or delays on your prefixes in the global  
routing tables.  Operators who didn't like this could complain to  
their governments, which would then decide whether and how to go to  
the World Trade Organization.

When the zombie apocalypse hits, I want all the walking dead to be  
nuked from space.  It's the only way to be sure.  Alas, I don't rule  
the world.  We'll probably be stuck with a solution much more  
jackbooted and less effective.  Like stateful filtering middleboxes  
that have to be told to open pinholes for the IKE port.