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

[QIU Ying]

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