Subject: [BEHAVE] Brief review of draft-soliman-firewall-control-00.txt

From: Martin Stiemerling <[email-masked]>
Date: Thu, 6 Dec 2007 21:19:56 +0100

Hi all,

I have had some remarks at the IETF#70 BEHAVE session about draft- 
soliman-firewall-control-00.txt.  I promised to summarise them and  
here we go. Sorry for being at brief on protocol details, but I have  
concerns about the proposal that do not require to get even to the  
protocol itself.

I like the idea of using CGA to identify clients in signal protocols,  
especially in environments where  you do not have a pre-knowledge  
(e.g., certificates, etc). This part is worth investigating further!

But when reading the draft and looking at the slides I have had the  
feeling that the authors had a great idea about security. However,  
they have tried to find a problem to fit their security ideas.

When reading Section  3.  "Protocol operation" it looks pretty much  
as the MIDCOM architecture (RFC3303). Finding the corresponding  
server that controls the firewall or the firewall itself is not an  
new idea and has been discussed back in the very beginning of MIDCOM  
(i.e., using a DHCP option for that). Other detection mechanisms have  
also been discussed.

Then there is NSIS which can discover NSIS-enabled firewalls/NATs  
easily and deals good with nested firewalls. You mention NSIS NATFW  
NSLP in Section 2. "Introduction" and claim that " However, this  
approach assumes a form of   pre-established trust." While is  
probably true for some possible deployments, it is just dead wrong in  
general. The NATFW NSLP, or NSIS in general, is open to other  
mechanisms that do not require pre-established trust and we have  
discussed some approaches to this in the past. For non-technical  
reasons, this has not made it in the working group drafts.

Then you have mentioned SIMCO (RFC4540). You have claimed on your  
slides that your protocol proposal is better than SIMCO, because you  
are running binary. Damn, you should read RFC4540 and see how binary  
SIMCO is. It is binary only and there is no notion at all of ABNF.

Using ICMPv6 as firewall/NAT (policy in general) transport protocol  
is for sure not the way of doing it. How about congestion control? I  
know where this idea comes from (MIP6) but it is an excellent  
approach at all to go down this road for firewall/NAT control purposes.

I would claim you have neglected searching for existing and related  
work.

Just my two cents,

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,  
London W3 6BL | Registered in England 2832014

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 6 Dec 2007 16:54:42 -0500

Hello,

I was involved in MIDCOM, client enabled firewall, off-path firewall
control, H.248v3 firewall/NAT control (Ia IMS interface), and other
related efforts. After all this I'm wondering if the IETF shouldn't
backtrack a little bit and try to standardize Firewall behavior (just
like it is doing for NAT), before we try to put effort in yet another
firewall control protocol. 
 
Thanks,

Reinaldo

________________________________

	From: Martin Stiemerling [mailto:[email-masked]] 
	Sent: Thursday, December 06, 2007 12:20 PM
	To: [email-masked]
	Subject: [BEHAVE] Brief review of
draft-soliman-firewall-control-00.txt

	Hi all, 

	I have had some remarks at the IETF#70 BEHAVE session about
draft-soliman-firewall-control-00.txt.  I promised to summarise them and
here we go. Sorry for being at brief on protocol details, but I have
concerns about the proposal that do not require to get even to the
protocol itself. 

	I like the idea of using CGA to identify clients in signal
protocols, especially in environments where  you do not have a
pre-knowledge (e.g., certificates, etc). This part is worth
investigating further!

	But when reading the draft and looking at the slides I have had
the feeling that the authors had a great idea about security. However,
they have tried to find a problem to fit their security ideas. 

	When reading Section  3.  "Protocol operation" it looks pretty
much as the MIDCOM architecture (RFC3303). Finding the corresponding
server that controls the firewall or the firewall itself is not an new
idea and has been discussed back in the very beginning of MIDCOM (i.e.,
using a DHCP option for that). Other detection mechanisms have also been
discussed. 

	Then there is NSIS which can discover NSIS-enabled
firewalls/NATs easily and deals good with nested firewalls. You mention
NSIS NATFW NSLP in Section 2. "Introduction" and claim that " However,
this approach assumes a form of   pre-established trust." While is
probably true for some possible deployments, it is just dead wrong in
general. The NATFW NSLP, or NSIS in general, is open to other mechanisms
that do not require pre-established trust and we have discussed some
approaches to this in the past. For non-technical reasons, this has not
made it in the working group drafts. 

	Then you have mentioned SIMCO (RFC4540). You have claimed on
your slides that your protocol proposal is better than SIMCO, because
you are running binary. Damn, you should read RFC4540 and see how binary
SIMCO is. It is binary only and there is no notion at all of ABNF.

	Using ICMPv6 as firewall/NAT (policy in general) transport
protocol is for sure not the way of doing it. How about congestion
control? I know where this idea comes from (MIP6) but it is an excellent
approach at all to go down this road for firewall/NAT control purposes.

	I would claim you have neglected searching for existing and
related work. 

	Just my two cents, 

	 Martin

	NEC Europe Limited | Registered Office: NEC House, 1 Victoria
Road, London W3 6BL | Registered in England 2832014

---

From: Melinda Shore <[email-masked]>
Date: Thu, 06 Dec 2007 17:01:14 -0500

> firewall control protocol.

That would be a "no."  The reason that BEHAVE is attempting to
come up with recommendations for NAT behavior is because variations
in behavior complicate STUN, or at least that was the original
intention.  That it's metastasized into something else is, I think,
irrelevant to the question you raised.

Personally, I'm unclear on why this draft got time on the agenda
since it's redundant with a number of existing efforts and is off-
topic to the group.  And as I said a few weeks ago, the reasons
that firewall "control" has not been successful are most certainly
not because we lack a *protocol*, for heaven's sakes.  We have a
number of them.

Melinda

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 06 Dec 2007 23:07:17 +0100

I see the value of draft-soliman-firewall-control-00.txt only in the CGA 
approach. It is an academic value -- still interesting.
This idea came up in the past already and can be added to other 
protocols in a fairly painless fashion ---- in case someone really needs 
this stuff.

Ciao
Hannes

---

From: Melinda Shore <[email-masked]>
Date: Thu, 06 Dec 2007 17:13:28 -0500

> protocols in a fairly painless fashion ---- in case someone really needs

Absolutely, and I'll point out that we used group keys in NLS
to achieve the same goals (securing relationships between unknown-
in-advance pairs; providing rudimentary authorization).

Melinda

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 6 Dec 2007 17:18:48 -0500

I agree that firewall control was not successful not because of a lack
of protocol.

But I would say that as much as NAT variations cause problems for STUN,
Firewall variations also cause problems for many protocols. For example,
the way different firewalls implementations handle TCP ultimately impact
application protocols that run over it. I think there is also something
to be said about ICMP and others.  

Regards,

Reinaldo

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 2:01 PM
> To: Reinaldo Penno; Martin Stiemerling; [email-masked]
> Subject: Re: [BEHAVE] Brief review of 
> That would be a "no."  The reason that BEHAVE is attempting 
> to come up with recommendations for NAT behavior is because 
> variations in behavior complicate STUN, or at least that was 
> the original intention.  That it's metastasized into 
> something else is, I think, irrelevant to the question you raised.
> 
> Personally, I'm unclear on why this draft got time on the 
> agenda since it's redundant with a number of existing efforts 
> and is off- topic to the group.  And as I said a few weeks 
> ago, the reasons that firewall "control" has not been 
> successful are most certainly not because we lack a 
> *protocol*, for heaven's sakes.  We have a number of them.
> 
> Melinda
>  
>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 7 Dec 2007 00:45:33 +0200

Le Friday 07 December 2007 00:01:14 ext Melinda Shore, vous avez écrit :
> topic to the group.

My understanding is that it was there because it looks similar to ALD, which 
was there in Chicago as add-on to the V6CPE document.

> And as I said a few weeks ago, the reasons that firewall 
> has not been successful are most certainly not because
> we lack a *protocol*, for heaven's sakes.  We have a 
> number of them.

Definitely. The reason is lack of vendor interests (hence the value of ALD but 
I'm going off-topic).

-- 
Rémi Denis-Courmont

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 7 Dec 2007 11:42:16 +1000

I have had some remarks at the IETF#70 BEHAVE session about
draft-soliman-firewall-control-00.txt. I promised to summarise them and here
we go. Sorry for being at brief on protocol details, but I have concerns
about the proposal that do not require to get even to the protocol itself. 

	I like the idea of using CGA to identify clients in signal
protocols, especially in environments where you do not have a pre-knowledge
(e.g., certificates, etc). This part is worth investigating further!

	But when reading the draft and looking at the slides I have had the
feeling that the authors had a great idea about security. However, they have
tried to find a problem to fit their security ideas. 

=> Ok, can you at least substantiate that claim with some details? I happen
to think that choosing the right authorisation mechanism is fundamental to
any host-based firewall control protocol. But I don't see how you can go
from that to concluding that we created a problem around CGAs. I think
that's not true.

	When reading Section 3. "Protocol operation" it looks pretty much as
the MIDCOM architecture (RFC3303). Finding the corresponding server that
controls the firewall or the firewall itself is not an new idea and has been
discussed back in the very beginning of MIDCOM (i.e., using a DHCP option
for that). Other detection mechanisms have also been discussed. 

=> That's good but what's the comment? Did the draft claim that no one ever
thought about this? 
Please give us comments that can improve the draft if you can. All of the
authors would appreciate any criticisms that can help improve the quality of
the work.

	Then there is NSIS which can discover NSIS-enabled firewalls/NATs
easily and deals good with nested firewalls. You mention NSIS NATFW NSLP in
Section 2. "Introduction" and claim that " However, this approach assumes a
form of pre-established trust." While is probably true for some possible
deployments, it is just dead wrong in general. The NATFW NSLP, or NSIS in
general, is open to other mechanisms that do not require pre-established
trust and we have discussed some approaches to this in the past. For
non-technical reasons, this has not made it in the working group drafts. 

=> Hopefully something will make it to the draft because I think the current
security model for the NSIS draft is not useful for many practical
deployments.

	Then you have mentioned SIMCO (RFC4540). You have claimed on your
slides that your protocol proposal is better than SIMCO, because you are
running binary. Damn, you should read RFC4540 and see how binary SIMCO is.
It is binary only and there is no notion at all of ABNF.

=> I'm not sure if you're the same person who made this comment in the
meeting, but someone made that comment. I think I read an old SIMCO personal
draft, I promise to read 4540. 

	Using ICMPv6 as firewall/NAT (policy in general) transport protocol
is for sure not the way of doing it. How about congestion control? 

=> I think for very large deployments TCP is not a scalable way of doing
this. In another life I worked on similar protocols for policy control and
we found that for those large deployments, especially with managed networks,
congestion control was a much lesser priority in the scheme of tradeoffs. 

I know where this idea comes from (MIP6) 

=> ?? Really? Now I don't think you've done your homework on MIP6.

Hesham

---

From: "Suresh Krishnan" <[email-masked]>
Date: Fri, 7 Dec 2007 03:42:39 -0500

Hi Martin,
  Thanks for your comments. I am sure there are other protocols which did
parts of what we do, and probably gigantic supersets of what we do. We will
take a closer look at all the references and try to see why they failed
to get deployed. Meanwhile, if you can review the protocol itself like you
promised, it would be much more helpful for us to try to improve it.

Thanks
Suresh

---

From: Melinda Shore <[email-masked]>
Date: Fri, 07 Dec 2007 08:34:04 -0500

> to be said about ICMP and others.

One of the major barriers to deployment has been that firewall
vendors have substantial sunk costs in their existing technologies,
and they tend to express those sunk costs as "competitive advantage,"
product differentiators," and so on.  Virtually all of the people
driving the traversal work early on, and I think even still, come
from the application side - specifically voice/multimedia applications.
We've failed to convince the firewall guys that a signaling approach
has some advantages over their current proprietary approaches, and I
think that it would be extremely difficult to interest them in
recommendations for uniform treatment of various transports for
similar reasons - it would wipe out what they see as market
differentiation.

Whether or not you buy that, I don't see any way to change that
perception unless and until the traversal work is seen as more
fundamental to networking and something of interest to those
outside the voice community, frankly.  It's a self-perpetuating
problem.

Melinda