<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16414" name=GENERATOR></HEAD>
<BODY dir=ltr text=#000000 bgColor=#ffffff>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff 
size=2></FONT>&nbsp;</DIV><FONT face=Arial color=#0000ff size=2></FONT><BR>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> mip6-firewall-bounces@zeke.ecotroph.net 
  [mailto:mip6-firewall-bounces@zeke.ecotroph.net] <B>On Behalf Of </B>Yaron 
  Sheffer<BR><B>Sent:</B> Wednesday, March 21, 2007 5:43 AM<BR><B>To:</B> Qiu 
  Ying<BR><B>Cc:</B> mip6-firewall@zeke.ecotroph.net<BR><B>Subject:</B> Re: 
  [Mip6-firewall] BU to HA<BR></FONT><BR></DIV>
  <DIV></DIV>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm">Hi,</P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><FONT face=Arial color=#0000ff 
  size=2></FONT><BR></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm">this seems to be much less of 
  an issue than I thought, or maybe I am missing something.</P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><FONT face=Arial color=#0000ff 
  size=2></FONT><BR></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm">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.<SPAN class=437162409-21032007><FONT face=Arial 
  color=#0000ff size=2>&nbsp;</FONT></SPAN></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007></SPAN>&nbsp;</P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007><FONT face=Arial color=#0000ff size=2>=&gt; The HA 
  address can't be known in advance because you need to consider&nbsp;roaming 
  users ....etc. Actually the src prefix should always be known to the FW 
  because it's topologically correct (from the same domain). . 
  </FONT>&nbsp;</SPAN><BR></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><FONT face=Arial color=#0000ff 
  size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial 
  color=#0000ff size=2></FONT><BR></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm">However if we do want the extra 
  security from the firewall, it would need to terminate this ESP (and 
  IKE).&nbsp;<SPAN class=437162409-21032007><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007></SPAN>&nbsp;</P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007><FONT face=Arial color=#0000ff size=2>=&gt; That's 
  not an option in MIP. Security has to be e2e. </FONT></SPAN></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007>&nbsp;</SPAN>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.</P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><FONT face=Arial color=#0000ff 
  size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial 
  color=#0000ff size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><FONT 
  face=Arial color=#0000ff size=2></FONT><BR></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm">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?<SPAN class=437162409-21032007><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007><FONT face=Arial color=#0000ff size=2>=&gt; I agree, 
  I don't get that either. </FONT></SPAN></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007>&nbsp;</SPAN></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><FONT face=Arial color=#0000ff 
  size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial 
  color=#0000ff size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><FONT 
  face=Arial color=#0000ff size=2></FONT><FONT face=Arial color=#0000ff 
  size=2></FONT><BR></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm">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).<SPAN class=437162409-21032007><FONT face=Arial 
  color=#0000ff size=2>&nbsp;</FONT></SPAN></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007><FONT face=Arial color=#0000ff size=2>=&gt; :) 
  </FONT></SPAN></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007><FONT face=Arial color=#0000ff 
  size=2>Hesham</FONT></SPAN></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><SPAN 
  class=437162409-21032007>&nbsp;</SPAN></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><FONT face=Arial color=#0000ff 
  size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial 
  color=#0000ff size=2></FONT><BR></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm">Thanks,</P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm">&nbsp;&nbsp;&nbsp; Yaron</P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm"><BR></P>
  <P style="MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm">Qiu Ying wrote:</P>
  <BLOCKQUOTE 
  cite=mid:162B8AFBFBBB2148A9A1B8F9C57534283DF044@mailbe01.teak.local.net 
  type="cite"><PRE wrap="">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: <A class=moz-txt-link-abbreviated href="mailto:mip6-firewall-bounces@zeke.ecotroph.net">mip6-firewall-bounces@zeke.ecotroph.net</A> on behalf of Hannes Tschofenig
Sent: Mon 3/19/2007 5:28 PM
To: <A class=moz-txt-link-abbreviated href="mailto:mip6-firewall@zeke.ecotroph.net">mip6-firewall@zeke.ecotroph.net</A>
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
<A class=moz-txt-link-abbreviated href="mailto:Mip6-firewall@zeke.ecotroph.net">Mip6-firewall@zeke.ecotroph.net</A>
<A class=moz-txt-link-freetext href="https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall">https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall</A>



------------ 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
<A class=moz-txt-link-abbreviated href="mailto:Mip6-firewall@zeke.ecotroph.net">Mip6-firewall@zeke.ecotroph.net</A>
<A class=moz-txt-link-freetext href="https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall">https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall</A>

  </PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>