Subject: RE: [mobile-ip] I-D ACTION:draft-mccann-mobileip-80211fh-01.txt

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 6 Nov 2002 00:58:35 +0100

Hi Pete, 

  > I could also ask how the old AR gets the mapping table information.
  > Without a standardized mechanism, we won't have interoperability.

=> Manual configuration? Why would this have any relationship to
interoperability?

  > That coupled with the fact that anticipated handover seems 
  > impossible
  > without a fairly exotic device driver implementation leads me to
  > believe that we should defer this sort of signaling until we
  > understand the issues better, and have talked things through with
  > people who participate in the IEEE.

=> I agree that we should have a standard API in IEEE for this. 
But I completely disagree that this justifies the removal of 
pr_RS and pr_RA. To me there are some pretty trivial reasons
that show that this is not a good idea:

- Anticipation is not bound to IEEE as I keep saying. On some
link layers, the pr_RS is redundant and no standard API is 
needed to allow a router to send a pr_RA unsolicited. 
- If we have the pr_RS then we can have the API afterwards
and people would already have a standard mechanism to use FMIPv6

- If we remove this, what would you tell IEEE that we need
the API for? or perhaps you're suggesting that we don't need
one. I don't see an alternative though.

- What good does removing this message do?? At least if people
have the right cards (like the one on my laptop), they can use 
this today. Why should we ban people from using this?

You're essentially requesting to disallow a mechanism that 
will work sometimes in IEEE802.11 and in future can work all the time, 
without providing a better substitute. Needless to say that
this mechanism will work on other (e.g. cellular) links.

Going with this logic, people should have never allowed
IP in cellular networks until ROHC was invented. Doesn't 
seem right.

  > 
  > On the other hand, the F-BU is just previous FA 
  > notification which has
  > been around for a long time.  

=> Not at all, this is an e2e message which has 
nothing to do with PFANE. If you don't believe me
see your own text below:

    I expect there will be a lot of
  > discussion about how to develop a security association with 
  > an access
  > router, similar to the discussion that gave rise to return 
  > routability
  > in MIPv6, and we should probably have a (small) set of preferred
  > techniques for doing that.  

=> So if it's been around for a long time, why is it
still so non-trivial to use it? :)

   I think the F-BU/BACK messages and the
  > related security considerations are more than enough to 
  > occupy the WG
  > (and to fill out a good sized internet draft) at this point in time.

=> We're not talking about inventing a new message and spending 
time on it, this is already in the draft and has been for almost
two years. This discussion is in fact occupying
the WG's time more. I think it would be better if we spend
this time to think of ways of securing the F-BU in an 
efficient way. 

Hesham

---

From: "Karim El-Malki (EAB)" <[email-masked]>
Date: Thu, 7 Nov 2002 15:03:02 +0100

Hi Pete

 > From the draft-05:
 > 
 >    3.2. Tunnel Establishment
 > 
 >       When the PAR receives a RtSolPr message, it transmits 
 > a Handover
 >       Initiate (HI) message to NAR, after looking up the IP address
 >       corresponding to the link-layer identifier supplied by the MN.
 > 
 > Why should the discovery process trigger a tunnel to be established,
 > even if it is a tunnel that isn't used for packet forwarding?  The
 > reason might have something to do with CoA establishment - but why
 > can't we take care of that after the handoff has completed, now that
 > we have a mechanism to continue using PCOA from the new AR?

The original concept with tunnelling from old AR to MN didn't
imply this. The tunnel was set up and data forwarded only after
you get the F-BU. I think the above behaviour (which is not clear in
the draft) was a consequence of changing the tunnel endpoint from MN to AR.
The important thing is that data is only forwarded after sending F-BU, so
the principle is the same, but I see your point. I'd be in favour of
reverting to the old agreed protocol, since this change wasn't discussed.

 >  >  > The good is to make the document simpler, so that it 
 > solves a problem
 >  >  > that we actually know how to solve, and which can work 
 > no matter what
 >  >  > firmware/driver architecture is in place.
 >  >  > 
 >  >  > I am not saying we should ban people from sending 
 > RtSolPr, just that
 >  >  > we don't have such a short-term need for it and we can 
 > standardize it
 >  >  > in a different document after a more careful 
 > consideration of how to
 >  >  > implement it on 802.11 networks.
 >  > 
 >  > Simplicity is good, but you can't cut down beyond a 
 > certain point otherwise
 >  > the document becomes incomplete. In fact, IMO adding the 
 > tunnel-based handover
 >  > made it much more complex than what Rajeev had earlier.
 > 
 > I agree; I now think something like tunnel-based could be done at the
 > link layer, within IEEE.

OK. If that is done carefully then I think it would provide a nice
fall-back mechanism. So I'd propose to take out the tunnel-based
handover part and make the spec more similar to the original one
(George Tsirtsis').

 > 
 >  > Anyway, the point
 >  > is that since there are cards that allow mobile-based L2 
 > triggers, RtSolPr
 >  > is needed. Also, 802.11 is a good starting point but I 
 > thought we agreed
 >  > that the basic FMIPv6 spec would not be based only on 
 > 802.11 requirements,
 >  > otherwise we'll have to do a new FMIPv6 spec per 
 > link-layer. I don't want to
 >  > get into the discussion of which other link-layers there 
 > may be, since there
 >  > won't be any link-layer which provides triggers if 
 > there's no IP protocol
 >  > like FMIPv6 requiring them. It would just get us nowhere.
 > 
 > It seems like this might be putting the cart before the horse.
 > Shouldn't we coordinate with the link layer standards bodies to make
 > sure what we need is in place?

I would think that since there's a lot of link-layer standards bodies
and one IETF, we could give the basic spec to the link-layer bodies
for feedback rather than waiting for input from each one. That would help
in doing the FMIPv6 over foo drafts. Of course, we shouldn't develop the
protocol only for one link-layer but we both agree that involvement
of other bodies is a good thing.

Rgds
/Karim

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Sun, 10 Nov 2002 23:31:13 +0100

Hi Behcet,

  > Can you please elaborate on how it is possible to implement 
  > anticipated 
  > HO signalling on WCDMA? I thought that even base MIPv6 
  > handover can not 
  > be implemented in WCDMA?

=> Why not? MIPv6 is access independent. The current FMIPv6
draft is also access independent because it allows the 
triggers to take place in the network or the MN. Everything
else is a matter of synching layer 2 and layer 3 handovers
together for a particular link layer. 

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 11 Nov 2002 20:50:14 +0100

> -----Original Message-----
  > From: Greg Daley [mailto:[email-masked]]
  > Sent: Monday, November 11, 2002 2:08 AM
  > To: James Kempf
  > Cc: Pete McCann; Karim El-Malki (EAB); Hesham Soliman (EAB);
  > [email-masked]
  > Subject: Re: [mobile-ip] I-D 
  > ACTION:draft-mccann-mobileip-80211fh-01.txt
  > 

  > 
  > All this complex decapsulation and caching behaviour in
  > access routers is possibly a premature optimization,
  > if address acquisition (which has to be improved anyway)
  > can be made to run faster.

=> So I'm not the only one who thinks that, Thank you!
It is an overkill to have this complex mechanism
when the probability of address collision (for random iids) is much 
smaller than the probability of any of the handover messages 
being lost, especially over the air interface.

  > When the tunnel is established (bidirectionally?)
  > the MN can do RR to the CN's if it likes
  > (or if this is necessary, we did talk about LMM before...).
  > This is where I see that the tunnel could be required.

=> Agreed.

Hesham

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 11 Nov 2002 14:41:39 -0600

-----Original Message-----
From: Hesham Soliman (EAB) [mailto:[email-masked]] 
Sent: Monday, November 11, 2002 2:28 PM
To: Khalil, Mohamed [RICH2:2N51:EXCH]
Cc: Alper E. YEGIN; Pete McCann; Rajeev Koodli;
[email-masked]; Charles E. Perkins
Subject: RE: [mobile-ip] I-D ACTION:draft-mccann-mobileip-80211fh-01.txt

  > > Furthermore, I'm pretty sure that ingress filtering is also 
  > > quite much beside the point.  If I read about what ingress 
  > > filtering is supposed to do, and the threats it is supposed 
  > > to protect against, then I don't see any relevance to this 
  > > discussion. 
  > > 
  > 
  > How about an untracable DoS attack? 

=> I think it is important for us to not break ingress filtering. This can
be done if outgoing packets are 
reverse tunnelled to the oAR. I don't see why we can't 
add this to the draft, for both anticipated and non anticipated handovers. 

MK>> What you are proposing is already there in the draft as follows: 

   "The key protocol operation involves setting up a routing path between 
   the two access routers to enable the MN to send and receive IP 
   packets while it establishes itself as a Mobile IPv6 end-point." 

   The 'routing path'  means forward and reverse tunnels  

=> Does it? It would be easier to just say "bidirectional tunnel".  

MK>> I agree that  'bidirectional tunnel' is a better word than 'path'

-Mohamed

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 11 Nov 2002 14:37:40 -0600

Hi James,

The ingress filter defines the addresses which could be passed or dropped as
follows:

    IF    packet's source address from within 204.69.207.0/24
    THEN  forward as appropriate

    IF    packet's source address is anything else
    THEN  deny packet

So, according to the above rule we could let the AR, when it receives HI
message, to add the following rule:

    IF    packet's source address from within 204.69.207.0/24
    THEN  forward as appropriate

    IF    packet's source address is MN's-oCOA/0
    THEN  forward as appropriate

    IF    packet's source address is anything else
    THEN  deny packet

Of course the actual implementation of those rules is just a table which
define the IP addresses and their ranges, which are allowed to pass. The
Access Router will add a new entry in this table for each MN's COA.

-Mohamed
-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Monday, November 11, 2002 1:32 PM
To: Alper E. YEGIN; Pete McCann
Cc: Rajeev Koodli; [email-masked]
Subject: Re: [mobile-ip] I-D ACTION:draft-mccann-mobileip-80211fh-01.txt

> I wasn't necessarily in agreement with the unspecified address use 
> actually, just topologically incorrect address use (e.g., oldCoA). And 
> this discussion does not relate to PANA discussion on unspec. address 
> use.
>
> How is this creating a major security hole? What is it that the 
> attacker can do, and how does the administrator of the access network 
> (collection of ARs and
> more) cannot identify the offender? Note that the pinhole in the 
> filter should just allow a host to send a FBU to one of the ARs, 
> that's it.
>

It allows someone to mount a DoS attack on the router. The attacker can't be
confined to operating from the same link because the old router could be at
arbitrary topological distance away from the new link.

            jak

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 11 Nov 2002 20:46:06 +0100

> How about an untracable DoS attack?

=> I think it is important for us to not break ingress
filtering. This can be done if outgoing packets are 
reverse tunnelled to the oAR. I don't see why we can't
add this to the draft, for both anticipated and non anticipated
handovers. 

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 11 Nov 2002 21:27:38 +0100

> How about an untracable DoS attack? 

=> I think it is important for us to not break ingress filtering. This can be done if outgoing packets are 
reverse tunnelled to the oAR. I don't see why we can't 
add this to the draft, for both anticipated and non anticipated handovers. 

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 11 Nov 2002 23:55:51 +0100

James,

  > > In the case where the MN doesn't anticipate the handover,
  > > we shouldn't rely on FBU/FBACK, since we're already in
  > > possession of an IP address in order to send the message
  > > to the oAR, and the oAR wasn't previously aware of our movement.
  > > This is the correct usage for BU to the oAR which
  > > was removed from MIPv6 base draft (issue 72).
  > >
  > > In the case where address acquisition optimizations aren't
  > > allowed and we haven't anticipated the handover...
  > > we don't know how often that will occur (so why optimize?).
  > >
  > 
  > Disagree. This is an architectural confusion between 
  > changing the routing id to
  > node id mapping and changing the routing for an existing, 
  > allocated address.
  > These are two different cases and they should be handled separately.

=> Mobile IPv6 deals with the change in the locator (IP address). 
There is no difference when this is between two visited
networks or a home network and a visited one. It's the 
same function. You choose to call the home address a "node id"
but it's still an interface id like any other IP address. 
Even if it identifies a virtual interface. 

Why should the two cases be treated separately?

Hesham

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 11 Nov 2002 14:41:39 -0600

-----Original Message-----
From: Hesham Soliman (EAB) [mailto:[email-masked]] 
Sent: Monday, November 11, 2002 2:28 PM
To: Khalil, Mohamed [RICH2:2N51:EXCH]
Cc: Alper E. YEGIN; Pete McCann; Rajeev Koodli;

-Mohamed