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

[Suresh Krishnan]

I will make the proposed changes and get back with a new draft by this 
weekend.

Thanks
Suresh

QIU Ying wrote:
> This description is sound much better.
> 
> ----- Original Message ----- 
> From: <Gabor.Bajko at nokia.com>
> To: <qiuying at i2r.a-star.edu.sg>; <mip6-firewall at zeke.ecotroph.net>
> Sent: Thursday, January 24, 2008 10:14 PM
> Subject: RE: [Mip6-firewall] New version (-03) of drafts
> 
> 
> Qiu wrote:
> 
> 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.
> 
> Snip ----
> 
> Ah, ok, if that is the intention, then we could append the text I
> proposed:
> 
> "When only a few priviledged nodes (like servers) are allowed to be
> contacted by outside nodes, then the following pattern will allow HoTI
> to reach these priviledged nodes:
> 
>      "Destination Address: CN Address
> 
>       Mobility Header Type: 1"
> 
> With CN address being the address of the priviledged nodes."
> 
> This would at least clarify the confusion I got in, and some other
> readers may get in.
> 
> - 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.--------------------------------------------------------
> 
> ------------ 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