[Mip6-firewall] New version (-03) of drafts

[Niklas Steinleitner]

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