[Mip6-firewall] FW: Latest version of the firewall Drafts

Tue Nov 27 21:55:05 EST 2007

Monday sounds better.

----- Original Message ----- 
From: "Vijay Devarapalli" <vijay.devarapalli at azairenet.com>
To: <Gabor.Bajko at nokia.com>
Cc: <mip6-firewall at zeke.ecotroph.net>
Sent: Wednesday, November 28, 2007 8:35 AM
Subject: Re: [Mip6-firewall] FW: Latest version of the firewall Drafts

>I can join Monday....
> 
> Vijay
> 
> Gabor.Bajko at nokia.com wrote:
>>  sorry, I intended to send it to the list ...
>> 
>> -----Original Message-----
>> From: Bajko Gabor (Nokia/MtView) 
>> Sent: Tuesday, November 27, 2007 3:35 PM
>> To: 'ext Yaron Sheffer'
>> Cc: suresh.krishnan at ericsson.com
>> Subject: RE: [Mip6-firewall] Latest version of the firewall Drafts
>> 
>> Hi Yaron,
>> 
>> I am fine with having a meeting discussing these two drafts in
>> Vancouver. We should agree the day&time and, to make the discussion more
>> efficient, the list of specific issues to be discussed. 
>> 
>> Here are a few possibilities for the day&time:
>> 
>> a) Sunday, December 2nd, any time between 3-9pm
>> b) Monday, December 3rd, any time between 3-9pm
>> 
>>>From the feedback sent to the list so far, Sunday seem to work for
>> Hannes, Niklas, Suresh and myself, but not for Yaron. What about Monday?
>> 
>> If we want to chat for two hours, we should meet no later than 7pm and
>> some time should also be reserved to discuss about the next steps
>> strategies. And Yaron, could you make a list of issues to be discussed
>> regarding the two existing drafts, and send them to the list beforehand?
>> 
>> All, please indicate your availability for Monday. Yaron, if you'll be
>> able to make it for Sunday evening, please let us know that too.
>> 
>> - gabor
>> 
>> 
>> -----Original Message-----
>> From: ext Yaron Sheffer [mailto:yaronf at checkpoint.com]
>> Sent: Tuesday, November 20, 2007 3:55 AM
>> To: Bajko Gabor (Nokia-SIR/MtView)
>> Cc: suresh.krishnan at ericsson.com
>> Subject: Re: [Mip6-firewall] Latest version of the firewall Drafts
>> 
>> Hi Suresh, Gabor,
>> 
>> 
>> I suggest that we meet in Vancouver for ~2 hours to brainstorm these two
>> drafts.
>> 
>> 
>> First, I believe that what we classify as vendor functionality can
>> actually be done by administrators, if the firewall is extensible
>> enough. I am actually working now to demonstrate this point.
>> 
>> 
>> Also, there's a variety of proposals on the table for firewall traversal
>> *protocols*. There are also a number of reasons why such protocols have
>> not been used in the past and will be hard to deploy in the future. So I
>> think a much more practical avenue would be small tweaks to MIPv6, so
>> that the firewall can open the right pinholes and the pinholes are as
>> tight as possible. Realistically, there is so little adoption of MIPv6
>> today that such tweaks should still be possible.
>> 
>> 
>> I am actually in favor of firewall traversal protocols, but I view them
>> as longer-term solutions. Making the secure adoption of MIPv6
>> conditional on them is in my opinion a mistake.
>> 
>> 
>> Please let me know if this makes sense.
>> 
>> 
>> Thanks,
>> 
>>     Yaron
>> 
>> 
>> Gabor.Bajko at nokia.com wrote:
>> 
>>> 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
>>> _______________________________________________
>>> Mip6-firewall mailing list
>>> Mip6-firewall at zeke.ecotroph.net
>>> https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
>>>
>>> Scanned by Check Point Total Security
>>>
>>>
>>>   
>> _______________________________________________
>> 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

------------ 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.--------------------------------------------------------