Subject: [BEHAVE] RE: Firewall control

From: "Dan Wing" <[email-masked]>
Date: Thu, 15 Nov 2007 09:55:21 -0800

(CC'ing BEHAVE)

On v6ops, Hesham Soliman wrote:

> We've submitted the draft below. I requested a slot from Fred 
> to discuss this in Vancouver.  I look forward to your input on 
> this.  We've received some comments from Dan Wing already about 
> some aspects of the draft which are underspecified or can be 
> improved. 

I have read both draft-soliman-firewall-control-00.txt and (previously) James
Woodyatt's ALD, draft-woodyatt-ald-01.txt.  At the BEHAVE working group
meeting at IETF69 in Chicago, James presented both v6ops-cpe-simple-security
and ALD.  Looking at the v6ops minutes, it appears James did not present ALD
to v6ops in Chicago but he did present v6ops-cpe-simple-security.

There is a lot of similarity between soliman-firewall-control and
woodyatt-ald.  As there are two proposals that provide a similar function, it
seems there is some community interest in creating a v6 protocol to allow
hosts to talk to v6 firewalls.  It would be to everyone's advantage to have
one solution, unless we 'want to see the desert bloom' with 3-4
non-interoperable standards like happened with v4 NATs.

The BEHAVE WG is only chartered for v4 NATs/NAPTs, but I have invited Hesham
to present soliman-firewall-control because BEHAVE working group members are
well-versed in the difficulties of simple CPE firewalling (a side-effect of v4
NAPTs), and I expect can provide constructive comments on the document.

I expect there may be sufficient interest in this topic to request a BoF in
Philadelphia, and have an informal meeting with interested parties in
Vancouver.  Thoughts?

-d

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 15 Nov 2007 19:09:40 +0100

The big question is "Why do you need yet another protocol?"

Another one would be: "Why do the IPv4 solutions don't work given that they are designed with extensibility in mind?"

-------- Original-Nachricht --------
> Datum: Thu, 15 Nov 2007 09:55:21 -0800
> Von: "Dan Wing" <[email-masked]>
> An: "\'Hesham Soliman\'" <[email-masked]>, "\'IPv6 Operations\'" <[email-masked]>
> CC: [email-masked]
> Betreff: [BEHAVE] RE: Firewall control

---

From: Melinda Shore <[email-masked]>
Date: Thu, 15 Nov 2007 13:45:21 -0400

On 11/15/07 2:09 PM, "Hannes Tschofenig" <[email-masked]> wrote:
> Another one would be: "Why do the IPv4 solutions don't work given that they
> are designed with extensibility in mind?"

The only work I saw the Soliman draft reference was NSIS, which
uses a different signaling model.  There's been a lot more work
done closer to the client-server model, which is what they're
proposing also, and I gather that they're not familiar with it.

I think that you're closer to right about what the real question
is.  Nearly any solution to any problem introduces new problems,
and I think in general the new problems introduced by both path-
coupled and path-decoupled middlebox signaling are sufficiently
intractible that we either end up resisting doing them at all or
choose instead to go with a bunch of hacked-up messy stuff that's
very situational.  

I realize that the IETF doesn't do architecture but it seems to
me that somehow this bigger question needs to be handled before
putting effort into a different version of the same old thing.

Melinda

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 16 Nov 2007 11:24:58 +1000

> <[email-masked]> wrote:

=> I would appreciate a link to something that I can read about similar
proposals in this area. I'm aware of James' work and probably should have
added it to the references but unintentionally didn't. 

 > choose instead to go with a bunch of hacked-up messy stuff that's

=> I find it difficult to discuss a wide range of problems in different
deployments on such generic level. Of course every solution introduces new
problems but that is never a reason to dismiss a solution IMHO. There is
also a wide range of firewall deployment scenarios as you know and while I
can think of some that don't need this approach, others definitely do. 

So I agree with one aspect of Hannes question, which is: what was the
problem with other proposals. Lets discuss that. The first part of the
question is not really useful because it doesn't tell us what those
solutions are that we're supposed to compare with. 

Hesham

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 15 Nov 2007 17:02:28 -0800

> => I would appreciate a link to something that I can read 
> about similar proposals in this area. I'm aware of James' work 
> and probably should have added it to the references but 
> unintentionally didn't. 

draft-eggert-middlebox-control-survey-01.txt surveys most of
the efforts around NAT (and firewall) control including NAT-PMP,
NSIS NATFW NSLP, UPnP IGD, and James Woodyatt's ALD.  There are
placeholders for MIDCOM, RSIP, STUN Control, NLS, AFWC, and 
RSIP.

> => I find it difficult to discuss a wide range of problems in 
> different deployments on such generic level. Of course every 
> solution introduces new problems but that is never a reason to 
> dismiss a solution IMHO.  There is also a wide range of 
> firewall deployment scenarios as you know and while I
> problem with other proposals.  Lets discuss that.

draft-eggert-middlebox-control-survey-01.txt describes them, but
doesn't get into what's wrong with them.  The original SAFE BoF 
request hits on a few things that are wrong (an updated description
of the SAFE BoF will be available shortly, but here was the earlier
version):
  http://www.employees.org/safe/bof-request.html

Some of those might be applicable to v6 incarnations of those
protocols, too; I haven't thought about that aspect enough to
comment intelligently.

-d

> The first part of the

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 16 Nov 2007 10:05:14 +0200

> The big question is "Why do you need yet another protocol?"

We probably don't. Obviously, we not only don't need multiple protocols, but 
we don't want multiple protocols to do the same thing.

> are designed with extensibility in mind?"

Actually, they don't really work all that well (UPnP IGD, NAT-PMP, STUN 
control). These "pragmatic" solutions to IPv4 firewall control are heavily 
biased toward NAT traversal.

They use UDP as carrier. They use the middlebox "external" IP address toward 
the outside, rather than the IP address of the end node. Also, NAT-PMP and 
IGD are limited to first-hop because they use link-local multicast discovery.

And of course, these protocol would only deal with UDP and TCP 'cause that's 
the only protocols that pass through NATs.

With IPv6, I do not-so-humbly think it makes a lot of sense to use ICMPv6 as 
carrier (and follow IPv6/ICMPv6 formatting convention, including 64-bits 
alignment). It also makes sense to deliver the firewall control address 
through IPv6 means such as ICMPV6 RA or DHCPv6. In fact, both James and 
Hesham proposals do that.

-- 
Rémi Denis-Courmont

---

From: Melinda Shore <[email-masked]>
Date: Fri, 16 Nov 2007 08:35:16 -0500

> placeholders for MIDCOM, RSIP, STUN Control, NLS, AFWC, and

There is also SIMCO, which has been implemented as part of
Asterisk.

> protocols, too; I haven't thought about that aspect enough to

I think the basic problem is one that's really impossible to
address in the IETF, which is that IP and talking to middleboxes
are pretty much incompatible.  You don't just need to know
network topology, you need to know routing state, as well.  The
path-coupled stuff comes closer to being able to handle this
but NAT is a big fat problem for reachability.  In spite of this
I tend to think that path-decoupled approaches will tend to be
more deployable but I'm pretty sure we don't need yet another
one.

Melinda

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 17 Nov 2007 01:57:40 +1000

> biased toward NAT traversal.

=> That's exactly right. A lot of this is inherited from the FW == NAT
world. 

Hesham

---

From: Melinda Shore <[email-masked]>
Date: Fri, 16 Nov 2007 10:05:23 -0500

> => That's exactly right. A lot of this is inherited from the FW == NAT

Some are, some aren't.  UPnP IGD is not so much, nor are midcom or SIMCO
or a bunch of the others that haven't worked out.  Part of the issue
in the IETF has been that real-world problems around NAT traversal have
tended to dominate the problem space, and that's reasonable.

We've got a draft on differences between firewall and NAT traversal that
we'll be sending in when the submissions open up again.  One issue to
consider is that firewalls instantiate policy, and that the firewall
traversal work so far hasn't focused that much on policy interactions.

Melinda

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 16 Nov 2007 17:27:02 +0200

Le Friday 16 November 2007 17:05:23 ext Melinda Shore, vous avez écrit :
> Some are, some aren't.  UPnP IGD is not so much,

Uh? UPnP is about mapping external ports to internal ones, and getting the 
external address of the middlebox. Now, if that's not NAT centric...

> traversal work so far hasn't focused that much on policy interactions.

A firewall that has an "advanced" policy such as what you'll find in a typical 
corporate network most certainly does not want to be controlled anyway.

But then, there are "stateful" firewalls, whose policy it is to 
let "solicited" traffic in. As far as we had a nice client-server model, that 
worked very well. Nowadays we have "peer-to-peer" stuff such as end-to-end 
SIP media, or p2p file transfers. I have got to believe the main use cases 
for *IPv6* firewall control, is to tell a (loose) stateful firewall 
what "solicited" traffic is, whenever the on-the-wire packets are not 
sufficient. A host would know what its solicited traffic is, pretty much by 
definition.

Typical use cases are:
- your typical home LAN/WLAN access behind a stateful firewall CPE
  (what ALD is clearly designed for, and IMHO quite succesfully)
- cellular networks accesses where pay-per-bit, DoS concerns, battery 
lifetime, etc. pretty much require the use of stateful firewall
  (Hesham draft seems to address this)

IMHO, better merge these two documents (or kill either of them), than create a 
third one at this point. And they probably have sufficient features, that I'd 
rather not make the whole thing yet more complicated.

-- 
Rémi Denis-Courmont

---

From: Melinda Shore <[email-masked]>
Date: Fri, 16 Nov 2007 10:34:36 -0500

> external address of the middlebox. Now, if that's not NAT centric...

The last time I looked at it it also included firewall pinholing.

> corporate network most certainly does not want to be controlled anyway.

Back when we were trying to figure out what to call this work there
was a strong "suggestion" from Scott Bradner to call it "middlebox
communication" because we didn't want to imply that the endpoint or
its proxy was actually going to be controlling anything.  The problem
here isn't to allow applications to open pinholes on firewalls, but
rather for applications to request these network resources, give the
network/firewall sufficient information to say "yes" or "no," and
give the network a mechanism to communicate its decision back to the
endpoint.

What you describe as a "stateful" firewall actually behaves rather
like a NAT, and as you imply is missing a more granular policy
component.

Melinda

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 17 Nov 2007 11:19:23 +1000

> like a NAT, and as you imply is missing a more granular policy

=> I agree with this analysis but I don't think there is an issue with
missing policies. By decoupling the policy entity from the firewall you let
that decision be made in the PDP and simply gets "told" to the FW. There are
many architectures, especially in cellular networks, where this model makes
a lot of sense, especially when you consider that all the knowledge needed
to authorise the pinhhole is known at the PDP. 
I think the trickiest part with something like this is building the right
APIs for applications to make such requests. I guess that's what you are
saying above and I agree with that. But of course this is not the only
scenario where such API is needed, QoS signaling is another example where
this is needed. 

Hesham

---

From: james woodyatt <[email-masked]>
Date: Tue, 20 Nov 2007 14:18:05 -0800

On Nov 16, 2007, at 07:34, Melinda Shore wrote:
> On 11/16/07 10:27 AM, "Rémi Denis-Courmont" <remi.denis- 
> [email-masked]> wrote:

There are hints that UPnP IGD 2.0 may support firewall pinholing in  
IPv6 whenever it's eventually published.  I have seen no public  
documents yet, but I would be very surprised if this feature is  
inserted into the specification by any method beyond the  
straightforward method of extended the XML schemas to allow IPv6  
addresses and, possibly, to note that no NAT is necessary.

> give the network a mechanism to communicate its decision back to the

I'd like to point out that my ALD proposal is very deliberately  
presented with an inverted perspective on this.  The problem I tried  
to address is to give the stateful firewall a chance to discover  
application endpoint addresses that policy requires it to exempt from  
the general prohibition on blocking incoming packets not conforming  
to any existing state created by tracking the flow of outbound packets.

ALD is absolutely *NOT* a mechanism for applications to "control"  
firewalls, or even to "request" firewalls to open pinholes for them.   
It is a mechanism for firewalls to discover application listeners, so  
that incoming flows for those applications can be delivered to them  
properly, even when applications don't know in advance where those  
flows will originate.  Notice that ALD notifications go from nodes to  
firewalls, and acknowledgements are sent by firewalls solely for the  
purpose of telling nodes to stop sending notification retries.  No  
information is provided by firewalls to applications beyond that.   
This is quite intentional.

I think firewalls should be as transparent as possible, except when  
policy requires them to intervene.

In my humble opinion, ALD's primary virtue is that it correctly  
places the burden on the firewall not to destroy network transparency  
unnecessarily.  To that end, it aims to define a way for IPv6 node  
implementations to provide firewalls with enough information to  
behave transparently in the face of passive listening applications.   
It does not try to inform applications of the state of firewalls in  
the network.

We all still think applications shouldn't have to care, right?

I also think it's worth noting that any proposal for nodes/ 
applications to communicate with firewalls to solve these sorts of  
problems will inevitably involve disclosing the addresses of  
application passive listener endpoints when their users may not be  
expecting it.  I don't know how to prevent that from happening and  
still comply with the recommendations described in RFC 4864 and  
expanded in draft-ietf-v6ops-cpe-simple-security, but I don't think  
many participants here think this is a sensible security  
consideration.  Furthermore, I suspect many network operators will be  
very interested in mining the information stream produced by  
protocols of this class.

This is another virtue of ALD.  It gives operators the potential for  
some snooping goodness they can't get with current IPv6  
implementations, and it does so *without* larding their firewalls  
down with a lot of extra work trying to inform applications of things  
they shouldn't need to know.

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 21 Nov 2007 07:37:26 -0500

On 11/20/07 5:18 PM, "james woodyatt" <[email-masked]> wrote:
> unnecessarily.

Sure - that was a goal of midcom, too (restore some measure of
endy-to-endiness).  However, the problems that go along with that
include necessarily include things that make the network even
more visible still, like topology awareness (where is the firewall,
and how do you choose the right one?).  Those ancillary problems
remain unsolved and largely unaddressed, and it's difficult to
understand why there's an interest in another protocol to do the
same thing a bunch of others do (existing "off-path" firewall
protocols include [but are not limited to] midcom, SIMCO, and
UPnP IGD) while the all the problems they generate have not
been resolved.

Because there's no NAT involved v6 firewalling might be one place
where a path-coupled approach might actually be deployable, assuming
the authorization problems could be addressed.

Melinda