[Mip6-firewall] Way forward (Was Re: New version (-03) of drafts)

[Suresh Krishnan]

Hi Folks,
   I am waiting for the adoption consensus call to complete before I do 
any more work on these documents. If the documents are adopted we can 
submit -00 of the ietf-mext documents and make the substantial changes 
in the -01 since we need to get the wg to approve the changes. If there 
is no support for the document in the wg, I am not sure if we should 
continue working on them.

Thanks
Suresh

Niklas Steinleitner wrote:
>> Qui replied:
>> Not need to move it to another draft.. The type 5 mobility head would
>> not 
>> bring more threats than type 1 or 2 MH. 
>>
>> Snip ---
>>
>> If this is the agreement, then the text I proposed would be applicable
>> to sections 4.1, 4.2 as well as 4.3, right?
>>   
> Yes, we should add this in this sections, as well as in 4.5.
> 
> Niklas
>> - gabor
>>
>> -----Original Message-----
>> From: ext QIU Ying [mailto:qiuying at i2r.a-star.edu.sg] 
>> Sent: Thursday, January 24, 2008 3:29 AM
>> To: Bajko Gabor (Nokia-OCTO/MtView); mip6-firewall at zeke.ecotroph.net
>> Subject: Re: [Mip6-firewall] New version (-03) of drafts
>>
>> Hi, Gabor and Suresh
>>
>> my 2 cents inline
>>
>> ----- Original Message -----
>> From: <Gabor.Bajko at nokia.com>
>> To: <mip6-firewall at zeke.ecotroph.net>
>> Sent: Thursday, January 24, 2008 6:38 AM
>> Subject: Re: [Mip6-firewall] New version (-03) of drafts
>>
>>
>>   
>>> Hi Suresh,
>>>
>>> I believe, we had a common understanding back in Vancouver regarding
>>>     
>> the
>>   
>>> need for the FWs to allow unsolicited traffic through, more
>>>     
>> specifically
>>   
>>> HoTI and CoTI. The admin draft says in 4.1, 4.2:
>>>
>>> Destination Address: CN Address
>>>
>>>      Mobility Header Type: 1 (2)
>>>
>>> While every node behind the FW can be a CN, and this draft talks about
>>> static pinholes, the above means that the FW must have a static
>>>     
>> pinhole
>>   
>>> with both dest and source addresses wildcard and only filter on MH.
>>> While the text in the draft does not necessarily contradict with this,
>>>     
>> I
>>   
>>> think we need to make it more explicit.
>>>     
>> Maybe it is too considerate. It is true that every node could be a CN,
>> but 
>> one of the firewall targets is not to allow every node touchable from 
>> external. For example, in current practice, only a few nodes behind a 
>> firewall could be access from outside.  If we delete the destination
>> address 
>> from this pattern, the rule would be too weak.
>>
>> Anyway, the administrator could configure this item with wildcard if he 
>> would like to open the firewall to all internal nodes. Therefore, my 
>> opinion, it is not necessary to eliminate this option.
>>
>>
>>   
>>> My proposal is to change the pattern my deleting the "Destination
>>> Address: CN Address" line and replace the sentence: "This pinhole
>>>     
>> allows
>>   
>>> the HoTI message from the HA to the CN to
>>>   traverse the firewall. " (both in 4.1 and 4.2, respectively) with
>>> "This pinhole allows any unsolicited packet with a MH set to one to
>>> pass. While allowing unsolicited traffic through the FWs may
>>>     
>> constitute
>>   
>>> a security threat in many cases, the limited scope of the HoTI (and
>>> CoTI) messages limit the threat possibility. Letting unsolicited
>>>     
>> traffic
>>   
>>> through the FWs is the only possibility of letting external nodes
>>> contact nodes behind the FWs. Local FW administrators may decide
>>>     
>> whether
>>   
>>> contacting nodes behind FWs is an allowed scenario for the FW
>>>     
>> protected
>>   
>>> network or not, and set up pinholes accordingly." or something like
>>>     
>> that
>>   
>>> (please feel free guys to reformulate if you have a better wording).
>>>     
>> Yes. It is appreciated that the detail security analysis could be
>> provided 
>> in this draft.
>>
>>   
>>> Regarding 4.3, didn't we agree to move this to the vendor draft and
>>>     
>> say
>>   
>>> that a dynamic pinhole based on CoT is going to be opened to allow the
>>> BU pass through?
>>>     
>> Not need to move it to another draft.. The type 5 mobility head would
>> not 
>> bring more threats than type 1 or 2 MH.
>>
>>   
>>> Regarding the vendor draft: I think the Intended status of it should
>>>     
>> be
>>   
>>> Standards Track (or experimental). The reason I say that is that if it
>>> is implemented in the FWs, then it will enable MIP6 through FWs, being
>>> implicitly part of the protocol.
>>>     
>> Good comments.
>>
>> Regards
>> Qiu Ying
>>
>>
>>   
>>> - 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: Wednesday, January 23, 2008 12:22 PM
>>> To: mip6-firewall at zeke.ecotroph.net
>>> Subject: [Mip6-firewall] New version (-03) of drafts
>>>
>>> Hi Folks,
>>>   I fixed one issue with wrong text in the admin draft and added Gabor
>>> as an author. I will submit the drafts this Saturday, if there are no
>>> further comments.
>>>
>>> Cheers
>>> Suresh
>>>
>>> _______________________________________________
>>> 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.--------------------------------------------------------
>> _______________________________________________
>> 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