<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1597" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV><SPAN class=187240714-08112007><FONT face=Arial color=#0000ff size=2>I
agree there is a mix of rules in the document. I will try to get this separated
out by the deadline. </FONT></SPAN></DIV>
<DIV><SPAN class=187240714-08112007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=187240714-08112007><FONT face=Arial color=#0000ff
size=2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=187240714-08112007><FONT face=Arial color=#0000ff
size=2>Suresh</FONT></SPAN></DIV>
<DIV><SPAN class=187240714-08112007></SPAN> </DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Gabor.Bajko@nokia.com
[mailto:Gabor.Bajko@nokia.com] <BR><B>Sent:</B> November 7, 2007 8:36
PM<BR><B>To:</B> steinleitner@cs.uni-goettingen.de<BR><B>Cc:</B> Suresh
Krishnan; qiuying@i2r.a-star.edu.sg;
mip6-firewall@zeke.ecotroph.net<BR><B>Subject:</B> RE: [Mip6-firewall] [MEXT]
Nemo/Mext meeting at IETF-70?<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=612185900-08112007>But I thought the draft already has a mix of 'static'
and 'dynamic' rules. If you look into section 5.4, the text says that the fw
adds a rule based on the BU message. That pinhole cannot be created statically,
thus data can not flow if the fw does not install the pinhole in 5.4, unless you
statically configure to allow any traffic to the CN (which is equal to removing
the fw).</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=612185900-08112007></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=612185900-08112007>And btw, similar text should be in 4.4. The text
currently wrongly states that the pinhole created in 4.3 will let data traffic
pass through. A pinhole with:</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=612185900-08112007>destination address: CN Address</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=612185900-08112007>source address: MN CoA</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=612185900-08112007>has to be created based on the BU.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=612185900-08112007></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=612185900-08112007>Also, 4.1 through 4.3 may not work if the CN is also an
MN not at home. But I am not sure if we want to address this
scenario.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=612185900-08112007></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=612185900-08112007>If we want to make things work with FWs which are not
MIP aware, we need additional things. That's what we tried to address with
Hannes in the two drafts we wote (whose links I sent
earlier).</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=612185900-08112007></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=612185900-08112007>- gabor</SPAN></FONT></DIV><FONT face=Arial
color=#0000ff size=2></FONT><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> ext Niklas Steinleitner
[mailto:steinleitner@cs.uni-goettingen.de] <BR><B>Sent:</B> Wednesday, November
07, 2007 5:30 AM<BR><B>To:</B> Bajko Gabor (Nokia-SIR/MtView)<BR><B>Cc:</B>
suresh.krishnan@ericsson.com; qiuying@i2r.a-star.edu.sg;
Roberto.Baldessari@nw.neclab.eu;
mip6-firewall@zeke.ecotroph.net<BR><B>Subject:</B> Re: [Mip6-firewall] [MEXT]
Nemo/Mext meeting at IETF-70?<BR></FONT><BR></DIV>
<DIV></DIV>Is this in the scope of this draft?<BR>I have thought that the draft
should show how you have to <U>'static</U>' configure your environment in a way
that it allows Mobile IPv6 signaling and data messags to pass through -
independently of the security aspects and how often/long this pinholes are
required; i.e. "if you static configure your firewalls in that way, you can use
MIPv6".<BR><BR>Is what you propose not a different document, that describes the
pinholes which are needed to be 'dynamically' installed by a MIP6 firewall
traversal solution (e.g. MIP6 aware FW, ...) to let the different MIPv6 packets
traverse, isn't it? In this case the pinholes can be much more specific than in
the draft, which allows it general, whereas such an document specified it only
for a certain flow.<BR><BR>Niklas<BR><BR><A class=moz-txt-link-abbreviated
href="mailto:Gabor.Bajko@nokia.com">Gabor.Bajko@nokia.com</A> schrieb:
<BLOCKQUOTE
cite=mid:E5E76343C87BB34ABC6C3FDF3B31272701A6991D@daebe103.NOE.Nokia.com
type="cite"><PRE wrap="">Suresh,
If you update the draft, you may want to consider to clarify that some
of the described pinholes are 'static', i.e. they can be created by the
admin in advance, while the other pinholes are 'dynamic', i.e. they have
to be created on the go. The creation of these latter pinholes require
the FWs to be MIP stateful, while current firewalls do not understand
MIP (filters on MH are not possible yet either, at least not in
commercial FWs). Even if MIP stateful FWs are gonna be out there in the
foreseeable future, the current situation will persist until all FWs are
upgraded. This way the readers may get an idea on what MIP operations
can be supported by the current firewalled environment.
- gabor
-----Original Message-----
From: <A class=moz-txt-link-abbreviated href="mailto:mip6-firewall-bounces@zeke.ecotroph.net">mip6-firewall-bounces@zeke.ecotroph.net</A>
[<A class=moz-txt-link-freetext href="mailto:mip6-firewall-bounces@zeke.ecotroph.net">mailto:mip6-firewall-bounces@zeke.ecotroph.net</A>] On Behalf Of ext Suresh
Krishnan
Sent: Tuesday, November 06, 2007 7:21 AM
To: QIU Ying
Cc: Roberto Baldessari; <A class=moz-txt-link-abbreviated href="mailto:mip6-firewall@zeke.ecotroph.net">mip6-firewall@zeke.ecotroph.net</A>
Subject: Re: [Mip6-firewall] [MEXT] Nemo/Mext meeting at IETF-70?
Hi Ying,
I already have started updating the firewalls draft. I will send out
a pre-release by Thursday this week. I made some modifications to
account for the fact that the IPSec b/w the MN and the HA offers only
authentication and not confidentiality.
Thanks
Suresh
QIU Ying wrote:
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">Hi, Firewall Folks:
Should we update our draft "draft-krishnan-mip6-firewall-01" according
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">to the feedback getting at IETF69?
My comments are below"
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">6. Firewall Recommendations for MIPv6
I-D: draft-krishnan-mip6-firewall-01 15 min
Suresh Krishnan
--------------------------------------
* presentation:
- different scenario: firewall protecting HA, MN, CN, respectively
- recommends which kind of traffic should not be blocked by firewalls
- Adopt as WG draft?
* discussion
- hesham: just to clarify, only some firewalls in enterprise networks
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=""><!---->
</PRE>
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite"><PRE wrap="">block ipsec. Not in public networks
- frank: your solution makes network less safe (let all IPsec traffic
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=""><!---->
</PRE>
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite"><PRE wrap="">to HA through).
- Suresh: but this is the HA service, you have to let this
traffic through
</PRE></BLOCKQUOTE><PRE wrap="">Frankly, in practice realm, home agents are very special nodes: 1)
only few nodes are charged as home agents within a networks. 2) Home
agent is normally functioned as a server or a stationary machine at
least, so it is strong enough to protect itself (e.g. Jari mentioned
access mechanisms) and not have to rely on the protection of firewall.
A firewall that opens few channels for some specified robust nodes do
not means to weaken the strength of network security.
But in order to prevent the flood attacks, the firewall can constrain
the throughput of these channels.
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">- Alex: some operators don't want to allow RO due to security
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=""><!---->weaknessses
</PRE>
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite"><PRE wrap=""> - Suresh: that's why we separated rules for RO and for non-RO
</PRE></BLOCKQUOTE><PRE wrap="">No matter RO or non RO, the issue of IPsec packets through a firewall
can not avoid due to home binding update.
Any more comments?
Regards
Qiu Ying
----- Original Message -----
From: "Roberto Baldessari" <A class=moz-txt-link-rfc2396E href="mailto:Roberto.Baldessari@nw.neclab.eu"><Roberto.Baldessari@nw.neclab.eu></A>
To: <A class=moz-txt-link-rfc2396E href="mailto:nemo@ietf.org"><nemo@ietf.org></A>; <A class=moz-txt-link-rfc2396E href="mailto:mext@ietf.org"><mext@ietf.org></A>
Sent: Tuesday, November 06, 2007 5:18 PM
Subject: [MEXT] Nemo/Mext meeting at IETF-70?
Hi all,
According to the IETF draft agenda, no NEMO nor MEXT WG meeting has
been scheduled yet. Are there plans to have one at IETF-70?
Concerning the activity on automotive requirements for NEMO RO, we are
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">in the process to update the doc according to the feedback we got at
IETF-69 and preparing it to include/unify requirements from both
C2C-CC and ISO CALM.
Anyway, as (I guess) the contributions from CALM won't be ready in
time for IETF-70, I don't have anything against waiting until IETF-71
to present a more complete document. Also, I hope that by then MEXT WG
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">will be actually in place.
Best regards,
Roberto
================================================
Roberto Baldessari
Research Scientist
NEC Laboratories, Network Division, NEC Europe Ltd.
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel. +49 (0)6221 4342-167
Fax: +49 (0)6221 4342-55
e-mail: <A class=moz-txt-link-abbreviated href="mailto:roberto.baldessari@nw.neclab.eu">roberto.baldessari@nw.neclab.eu</A>
web: <A class=moz-txt-link-freetext href="http://www.netlab.nec.de/">http://www.netlab.nec.de/</A>
NEC Europe Limited | Registered Office:
NEC House, 1 Victoria Road, London W3 6BL Registered in England
2832014 ================================================
_______________________________________________
MEXT mailing list
<A class=moz-txt-link-abbreviated href="mailto:MEXT@ietf.org">MEXT@ietf.org</A>
<A class=moz-txt-link-freetext href="https://www1.ietf.org/mailman/listinfo/mext">https://www1.ietf.org/mailman/listinfo/mext</A>
------------ Institute For Infocomm Research - Disclaimer
-------------This email is confidential and may be privileged. If you
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">are not the intended recipient, please delete it and notify us
immediately. Please do not copy or use it for any purpose, or disclose
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">its contents to any other person. Thank
you.--------------------------------------------------------
_______________________________________________
Mip6-firewall mailing list
<A class=moz-txt-link-abbreviated href="mailto:Mip6-firewall@zeke.ecotroph.net">Mip6-firewall@zeke.ecotroph.net</A>
<A class=moz-txt-link-freetext href="https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall">https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall</A>
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
_______________________________________________
Mip6-firewall mailing list
<A class=moz-txt-link-abbreviated href="mailto:Mip6-firewall@zeke.ecotroph.net">Mip6-firewall@zeke.ecotroph.net</A>
<A class=moz-txt-link-freetext href="https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall">https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall</A>
_______________________________________________
Mip6-firewall mailing list
<A class=moz-txt-link-abbreviated href="mailto:Mip6-firewall@zeke.ecotroph.net">Mip6-firewall@zeke.ecotroph.net</A>
<A class=moz-txt-link-freetext href="https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall">https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall</A>
</PRE></BLOCKQUOTE><BR><PRE class=moz-signature cols="72">--
Niklas Steinleitner Tel: +49 551 3913583
Institute for Informatics <A class=moz-txt-link-abbreviated href="mailto:steinleitner@cs.uni-goettingen.de">steinleitner@cs.uni-goettingen.de</A>
University of Göttingen <A class=moz-txt-link-freetext href="http://www.tmg.informatik.uni-goettingen.de">http://www.tmg.informatik.uni-goettingen.de</A>
Lotzestrasse 16-18
D-37083 Göttingen, Germany</PRE></BODY></HTML>