[Mip6-firewall] BU to HA

Wed Mar 21 03:57:49 EDT 2007

From: Yaron Sheffer [mailto:yaronf at checkpoint.com]
Sent: Wed 3/21/2007 2:43 AM
To: Qiu Ying
Cc: Hannes Tschofenig; mip6-firewall at zeke.ecotroph.net
Subject: Re: [Mip6-firewall] BU to HA

>Hi,

>

>this seems to be much less of an issue than I thought, or maybe 

>I am missing something.

Hi, Yaron

>I can live with a policy like (src=any, dest=HA, prot=ESP). The HA 

>is a very specific host and can probably protect itself. 

Yes. in this case, problem is simple.

>However if we do want the extra security from the firewall, it would 

>need to terminate this ESP (and IKE). When discovering the HA 

>(or when the HAaddress is provisioned into the MN) it would be 

>better if we could provide the address of a security gateway (SeGW). 

>The BU can then be secured by tunnel-mode ESP up to the SeGW.

It is not always possible to provide the SeGW address to an individual node. 

One of reviewers for RFC 4487 mentioned that the RFC must consider

the scenario of  transit networks. So if the HA are protected by more than

one firewalls, should we provide all of these SeGW's addresses?  

Moreover, is the packet beteen SeGW to HA still protected by IPsec?

Otherwise, the operation of RFC 3776 also need to be changed accordingly. 

>I don't understand your point about no doing IKE. I don't know 

>anybody doing IPsec without IKE, it is extremely hard to scale such 

>solutions. Or did you have something else in mind?

No. I did not give up the IKE. We still need IKE to establish and update

the session key for IPsec. My idea is that when MN roams to new location 

and the established key is still valid, it is not necessary to negotiate a

new session key for the new BU message since the current SA could be 

found according to SPI and HoA.

>I think the really bad issues are around Route Optimization, and possibly 

>the actual data tunnel (although I am willing to be convinced otherwise 

>about the data, Hesham almost did convince me this morning).

Sorry, I am not following that. Do you mean the data between MN and 

CN? Can be more detail?

Regards and Thanks

Qiu Ying

________________________________

From: Yaron Sheffer [mailto:yaronf at checkpoint.com]
Sent: Wed 3/21/2007 2:43 AM
To: Qiu Ying
Cc: Hannes Tschofenig; mip6-firewall at zeke.ecotroph.net
Subject: Re: [Mip6-firewall] BU to HA

Hi,

this seems to be much less of an issue than I thought, or maybe I am missing something.

I can live with a policy like (src=any, dest=HA, prot=ESP). The HA is a very specific host and can probably protect itself. Actually there's no benefit in adding the HoA into the rule, since it can be spoofed.

However if we do want the extra security from the firewall, it would need to terminate this ESP (and IKE). When discovering the HA (or when the HA address is provisioned into the MN) it would be better if we could provide the address of a security gateway (SeGW). The BU can then be secured by tunnel-mode ESP up to the SeGW.

I don't understand your point about no doing IKE. I don't know anybody doing IPsec without IKE, it is extremely hard to scale such solutions. Or did you have something else in mind?

I think the really bad issues are around Route Optimization, and possibly the actual data tunnel (although I am willing to be convinced otherwise about the data, Hesham almost did convince me this morning).

Thanks,

    Yaron

Qiu Ying wrote:

	Hi, 

	As discussed at breakfast, the major problem is how to let the binding update message to Home Agent through the firewall. As we know, the BU format is 
	     BU_HA = {Src=CoA, Dst=HA, Opt=HoA, ESP(Seq#, Lifetime, ... ... )},
	which use an unspecified source address (CoA) and the IPsec protocol type. 

	Before send the BU_HA, the MN and HA must negotiate the session key (currently use IKE) for the security tunnel. The firewalls should not block the signals during IKE negotiation. After IKE, the firewall should open to the MN's CoA.   

	However, due to the consideration of computing and processing time, the process of IKE is not always necessary. So, the problem is how the firewall deals with the BU_HA message with new CoA. The BU message is blocked by a firewall because of the IPsec protocol type (50) and variable source address (CoA). But the optional address in BU message is fixed (HoA). The conventional firewall never checks the optional address. We could propose to extend firewall features that could check the optional address in IPv6 network as well as the source address and destination address. 

	As for the packet protocol, we could add the mobility protocol type (135) prior to the IPsec protocol (50). Then we could ask the firewall to allow the packets with optional address (HoA) and protocol type 135. 

	Since the packets with mobility protocol type are very small and need less processing, even if a malicious node fakes other HoA at its optional address, it would not occur serious threats.

	Any comments?

	Regards
	Qiu Ying

	________________________________

	From: mip6-firewall-bounces at zeke.ecotroph.net on behalf of Hannes Tschofenig
	Sent: Mon 3/19/2007 5:28 PM
	To: mip6-firewall at zeke.ecotroph.net
	Subject: [Mip6-firewall] Prague Meeting, Tuesday Breakfast, 8am - 9am

	Hi all,

	let's meet for breakfast at the Hilton hotel (lobby) at 8am on Tuesday.

	Ciao
	Hannes

	_______________________________________________
	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

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