Subject: RE: [mobile-ip] FMIPv6: Sending FBU from the new link

From: "Mohamed Khalil" <[email-masked]>
Date: Tue, 11 Mar 2003 08:42:34 -0600

Hi Rajeev,

I think we could allow a controlled and authorized access of a MN to the new
subnetwrok using its oCOA. In a previous email I have indicated how the
ingress filter could allow dynamically certain source IP addresses to be
forwarded through the new sub-network. The proposed solution is workable
solution but it doesn't solve a problem which can't by solved by the
previous model. Moreover, it will complicate the protocol unnecessarily.

-Mohamed

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]] 
Sent: Monday, March 10, 2003 6:24 PM
To: [email-masked]
Subject: [mobile-ip] FMIPv6: Sending FBU from the new link

Hello folks,

I would like to follow up on the following e-mail. Specifically, I think it
would be better to have FBU terminate at the new AR, and let the new AR send
HI with the binding authorization from the MN (item 2) below). Perhaps
encapsulate FBU in HI.. That way, the FBU won't have to be forwarded 
with topologically inconsistent source IP address, 
potentially across multiple hops.

Regards,

-Rajeev

-------- Original Message --------
Subject: Re: [mobile-ip] Security Problems with FBU (was: Re: [mipcharter]
Proposed Charter for IPv6 Mobility)
Date: Wed, 05 Mar 2003 17:52:46 -0800
From: Rajeev Koodli <[email-masked]>
Organization: Nokia Research Center
To: James Kempf <[email-masked]>
CC: Mohamed Khalil <[email-masked]>,
[email-masked]
References:
<[email-masked]>
<025001c2e365$4b2eb730$156015ac@T23KEMPF>

I see two possible ways to handle this.

1) rate limit the FBUs sent from new link
2) allow NAR to send HI, as Jim has suggested, but include the
     binding authorization from the MN in HI.

-Rajeev

James Kempf wrote:

> If the MN sends the FBU message on the new AR, then the HI message 
> arrives at the new AR after the FBU is routed to the previous AR by 
> the new AR.
>
> Chicken and egg problem.
>
>             jak
>
> ----- Original Message -----
> From: "Mohamed Khalil" <[email-masked]>
> To: "'James Kempf'" <[email-masked]>
> Cc: <[email-masked]>; "Rajeev Koodli" 
> <[email-masked]>
> Sent: Wednesday, March 05, 2003 1:57 PM
> Subject: RE: [mobile-ip] Security Problems with FBU (was: Re: [mipcharter]
> Proposed Charter for IPv6 Mobility)
>
> > The oAR is sending an HI message with the pCOA to the nAR. I am 
> > assuming that the HI will be sent securely to the nAR through some 
> > type of security protocol such as IPSec (the definition of this 
> > protocol is suppose to be outside the scope of this draft). This 
> > implies that the owner of this pCOA has been granted access to the 
> > old subnetwork and is not an attacker. When the nAR receives HI 
> > message it is suppose to verify this message and part of the 
> > functionality is to add an entry for the MN's pCOA to the ingress 
> > filter table. I agree that there are some more work to be done in 
> > the area of securing FBU and HI/HACK which should be addressed by 
> > other future drafts as Rajeev indicated before.
> >
> >

[snip]

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 12 Mar 2003 16:48:06 +0100

Rajeev, 

I agree with Alper's first paragraph below, not 
the rest ;). I think the BU should be terminated at 
the old AR. 

Hesham

  > From: Alper Yegin [mailto:[email-masked]]
  > Sent: Tuesday, March 11, 2003 3:59 AM
  > To: Rajeev Koodli; [email-masked]
  > Subject: Re: [mobile-ip] FMIPv6: Sending FBU from the new link
  > 
  > 
  > Hi Rajeev,
  > 
  > I don''t think this is a good idea. This complicates the protocol
  > unnessarily. Allowing F-BU be sent from new link with oldCoA
  > as the source is a further enhancement or failure recovery to
  > the base FMIP protocol. 

I think it is reasonable to expect 
  > the access
  > network to optionally allow some limited packets  be sent 
  > with topologically
  > incorrect source address for this "bonus point". These packets
  > are such that they must be F-BU sent by an already authenticated MN,
  > source address must be from a prefix in the access network, 
  > destination
  > address can only be another AR in this network. And if the 
  > AR cares, it can
  > log them in case this mechanism is ever abused. This is not 
  > like opening an
  > access network's ingress filtering, or completely disabling ingress
  > filtering on the Internet.
  > 
  > So, imho, we shouldn't have to complicate the protocol by 
  > doing either
  > of what you suggested below.
  > 
  > alper
  > 
  > 
  > 
  > > Hello folks,
  > > 
  > > I would like to follow up on the following e-mail.
  > > Specifically, I think it would be better to have FBU
  > > terminate at the new AR, and let the new AR send HI
  > > with the binding authorization from the MN (item 2)
  > > below). Perhaps encapsulate FBU in HI..
  > > That way, the FBU won't have to be forwarded
  > > Subject: Re: [mobile-ip] Security Problems with FBU (was: Re:
  > > [mipcharter] Proposed Charter for IPv6 Mobility)
  > >> If the MN sends the FBU message on the new AR, then the 
  > HI message arrives at
  > >> the new AR after the FBU is routed to the previous AR by 
  > the new AR.
  > >> 
  > >> Chicken and egg problem.
  > >> 
  > >>             jak
  > >> 
  > >>> The oAR is sending an HI message with the pCOA to the 
  > nAR. I am assuming
  > >>> that the HI will be sent securely to the nAR through 
  > some type of security
  > >>> protocol such as IPSec (the definition of this protocol 
  > is suppose to be
  > >>> outside the scope of this draft). This implies that the 
  > owner of this pCOA
  > >>> has been granted access to the old subnetwork and is 
  > not an attacker. When
  > >>> the nAR receives HI message it is suppose to verify 
  > this message and part of
  > >>> the functionality is to add an entry for the MN's pCOA 
  > to the ingress filter
  > >>> table. I agree that there are some more work to be done 
  > in the area of
  > >>> securing FBU and HI/HACK which should be addressed by 
  > other future drafts as
  > >>> Rajeev indicated before.
  > >>> 
  > >>> 
  > > 
  > > [snip]
  > > 
  >