[Mip6-firewall] Latest version of the firewall Drafts
Gabor.Bajko at nokia.com
Gabor.Bajko at nokia.com
Sat Nov 17 18:11:12 EST 2007
Suresh,
I would have had a few more issues, but I saw you rushed to submit the
documents ...
Anyway, here are some issues which would need to be clarified at some
point in the drafts:
firewall-admin draft:
The abstract and intro section do not say that the static configuration
by itself is not enough to enable mip6 signalling and data traffic for
all scenarios.
Suggested remedy:
Replace the abstract section with this:
"This document presents some recommendations for firewall
administrators to help them configure their existing firewalls in a
way that allows in certain deployment scenarios the Mobile IPv6
signaling and data messages to pass through. For other scenarios, the
support of additional mechanisms to create pinholes required for MIPv6
will be necessary. This document assumes that the firewalls in question
include some kind of stateful packet filtering capability."
And the 2nd paragraph of the intro with this:
"This document presents some recommendations for firewall
administrators to help them configure their firewalls in a way that
allows in certain deployment scenarios the Mobile IPv6 signaling and
data messages to pass through. This document assumes that the firewalls
in question include some kind of stateful packet filtering capability.
The static rules that need to be configured are described in this
document. In some scenarios, the support of additional mechanisms to
create pinholes required for MIPv6 signalling and data traffic to pass
through will be necessary.
A possible solution, describing the dynamic capabilities needed for the
firewalls to create pinholes based on MIPv6 signalling traffic is
described in a companion document [MIP6FWVENDOR]. Other solutions may
also be possible."
It is important to emphasize that creation of pinholes based on MIPv6
traffic snooping is not the only possible solution.
The sentence "Since MNs do not usually provide
services, this is not usually a problem." from 3.3 should be deleted,
as it is not true any more.
Section 4.4:
The solution described in [MIP6FWVENDOR] is only one possible solution.
There should not be such a strong link between the documents. Modify the
sentence: "The stateful
firewall rules specified in [MIP6FWVENDOR] will open a pinhole for
this traffic."
To: "A dynamically created pinhole like the one e.g. in [MIP6FWVENDOR]
will open a pinhole for this traffic."
Section 4.5: creating a dynamic pinhole similar to the ones created in
section 5 of the vendor draft, but using the MN's HoA instead of the CoA
would solve this problem too. And add a sentence to the end of the
section: "This practice is NOT RECOMMENDED, instead a dynamically
created pinhole like the one e.g. in [MIP6FWVENDOR] will open a pinhole
for this traffic."
Firewall-vendor draft:
Section 5: Create a pinhole for the bi-directional tunnelled traffic as
suggested above.
- gabor
-----Original Message-----
From: mip6-firewall-bounces at zeke.ecotroph.net
[mailto:mip6-firewall-bounces at zeke.ecotroph.net] On Behalf Of ext Suresh
Krishnan
Sent: Thursday, November 15, 2007 3:52 PM
To: mip6-firewall at zeke.ecotroph.net
Subject: [Mip6-firewall] Latest version of the firewall Drafts
Hi Folks,
I have enclosed the latest version of the firewall drafts. I believe
I have addressed all the comments I received. Please let me know if you
have any comments. I will submit the drafts this weekend if there are no
comments.
Cheers
Suresh
More information about the Mip6-firewall
mailing list