[Mip6-firewall] [MEXT] Nemo/Mext meeting at IETF-70?
Yaron Sheffer
yaronf at checkpoint.com
Wed Nov 7 08:45:28 EST 2007
I think the draft should include both guidelines to firewall
administrators on how to configure the FW, and guidelines to firewall
vendors on how dynamic inspection of MIP6 should be done. Of course the
two should be clearly distinguished.
Regards,
Yaron
Niklas Steinleitner wrote:
> Is this in the scope of this draft?
> I have thought that the draft should show how you have to _'static_'
> 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".
>
> 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.
>
> Niklas
>
> Gabor.Bajko at nokia.com schrieb:
>> 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: mip6-firewall-bounces at zeke.ecotroph.net
>> [mailto:mip6-firewall-bounces at zeke.ecotroph.net] On Behalf Of ext Suresh
>> Krishnan
>> Sent: Tuesday, November 06, 2007 7:21 AM
>> To: QIU Ying
>> Cc: Roberto Baldessari; mip6-firewall at zeke.ecotroph.net
>> 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:
>>
>>> Hi, Firewall Folks:
>>>
>>> Should we update our draft "draft-krishnan-mip6-firewall-01" according
>>>
>>
>>
>>> to the feedback getting at IETF69?
>>>
>>> My comments are below"
>>>
>>>
>>>
>>>> 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
>>>>
>>
>>
>>>> block ipsec. Not in public networks
>>>> - frank: your solution makes network less safe (let all IPsec traffic
>>>>
>>
>>
>>>> to HA through).
>>>> - Suresh: but this is the HA service, you have to let this
>>>> traffic through
>>>>
>>> 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.
>>>
>>>
>>>
>>>> - Alex: some operators don't want to allow RO due to security
>>>>
>> weaknessses
>>
>>>> - Suresh: that's why we separated rules for RO and for non-RO
>>>>
>>> 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" <Roberto.Baldessari at nw.neclab.eu>
>>> To: <nemo at ietf.org>; <mext at ietf.org>
>>> 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
>>>
>>
>>
>>> 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
>>>
>>
>>
>>> 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: roberto.baldessari at nw.neclab.eu
>>> web: http://www.netlab.nec.de/
>>>
>>> NEC Europe Limited | Registered Office:
>>> NEC House, 1 Victoria Road, London W3 6BL Registered in England
>>> 2832014 ================================================
>>>
>>> _______________________________________________
>>> MEXT mailing list
>>> MEXT at ietf.org
>>> https://www1.ietf.org/mailman/listinfo/mext
>>>
>>>
>>> ------------ Institute For Infocomm Research - Disclaimer
>>> -------------This email is confidential and may be privileged. If you
>>>
>>
>>
>>> are not the intended recipient, please delete it and notify us
>>> immediately. Please do not copy or use it for any purpose, or disclose
>>>
>>
>>
>>> its contents to any other person. Thank
>>> you.--------------------------------------------------------
>>> _______________________________________________
>>> Mip6-firewall mailing list
>>> Mip6-firewall at zeke.ecotroph.net
>>> https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
>>>
>>
>> _______________________________________________
>> Mip6-firewall mailing list
>> Mip6-firewall at zeke.ecotroph.net
>> https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
>> _______________________________________________
>> Mip6-firewall mailing list
>> Mip6-firewall at zeke.ecotroph.net
>> https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
>>
>
> --
> Niklas Steinleitner Tel: +49 551 3913583
> Institute for Informatics steinleitner at cs.uni-goettingen.de
> University of Göttingen http://www.tmg.informatik.uni-goettingen.de
> Lotzestrasse 16-18
> D-37083 Göttingen, Germany
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mip6-firewall mailing list
> Mip6-firewall at zeke.ecotroph.net
> https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zeke.ecotroph.net/pipermail/mip6-firewall/attachments/20071107/9319d5d8/attachment.html
More information about the Mip6-firewall
mailing list