Subject: Firewall control

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 14 Nov 2007 14:14:26 +1000

Hi all, 

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. 

Hesham

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2007 9:15 AM
To: [email-masked]
Subject: I-D ACTION:draft-soliman-firewall-control-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Firewall Control for Public Access Networks (FCON)
	Author(s)	: H. Soliman, et al.
	Filename	: draft-soliman-firewall-control-00.txt
	Pages		: 45
	Date		: 2007-11-13
	
   This document proposes a new mechanism that allows end nodes to
   signal their preferences for traffic filters to a firewall function
   in the network or to another node that controls the firewall function
   in the network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-soliman-firewall-control-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-soliman-firewall-control-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-soliman-firewall-control-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 15 Nov 2007 21:25:37 +0200

Le Wednesday 14 November 2007 06:14:26 Hesham Soliman, vous avez écrit :
> this in Vancouver. I look forward to your input on this.

I really think, that for any practical matter, right to control the firewall 
should be granted if:
- you are behind the firewall and "own" the IP address,
- the request is allowed by local firewall policy.

I really question the point of asymetric cryptography here. It is going to be 
a pain to deploy. And lets face it, neither the end device, nor the firewall 
want to do public key operation. It's not exactly "cheap" in term of CPU.

Easy to deploy, safe and operational security: use simple return-path check, 
with a one-time token challenge (I suppose that's the cookie option you have 
already there).

Also, I doubt the assumption of DHCP is right. At least, in the typical v6cpe 
case, I don't quite expect alls routers and all clients to have it - many 
will stick to ND-based autoconf.

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

---

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

> - the request is allowed by local firewall policy.

=> Agreed.

 > want to do public key operation. It's not exactly "cheap" in 

=> Asymetric crypto is only needed for one message exchange. If it is an
issue
for future exchanges one can always derive a secret key for those exchanges.
But we don't really have evidence (yet) that this is a huge issue. If it is
an issue, it would be easy to avoid it after the initial
authentication/authorisation step.

 > will stick to ND-based autoconf.

=> We did have an RA option there but never had time to add it. Also, the
authors at the time discussed it and we thought that so far DHCP is the
choice for configuring services, so we stuck with that. However, I think if
the community prefers an RA option then this wouldn't be a big hurdle. But I
do think it's important to keep DHCP as an option.

Hesham