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

[Gabor.Bajko at nokia.com]

> Gabor wrote:
> 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?

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?

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