[Mip6-firewall] BU to HA

[Hesham Soliman]

  _____  

From: mip6-firewall-bounces at zeke.ecotroph.net
[mailto:mip6-firewall-bounces at zeke.ecotroph.net] On Behalf Of Yaron Sheffer
Sent: Wednesday, March 21, 2007 5:43 AM
To: Qiu Ying
Cc: 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. 

 

=> The HA address can't be known in advance because you need to consider
roaming users ....etc. Actually the src prefix should always be known to the
FW because it's topologically correct (from the same domain). .  





However if we do want the extra security from the firewall, it would need to
terminate this ESP (and IKE).  

 

=> That's not an option in MIP. Security has to be e2e. 

 

 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 agree, I don't get that either. 

 




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

 

=> :) 

 

Hesham

 




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



  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zeke.ecotroph.net/pipermail/mip6-firewall/attachments/20070321/b612b84e/attachment-0001.html