Subject: [mobile-ip] Return Routability

From: Robert Chalmers <[email-masked]>
Date: Mon, 04 Mar 2002 18:15:15 -0800

Hopefully a quick question:

In the past, there were a number of proposals for RR, e.g., bu-3way and
bake/2.  Since then, security analysis has shown that two sets of
messages, 1a/b and 2a/b from the DT recommendation, should be involved. 
However, not much has been said about which technique would be most
appropriate to extend with the extra messaging.  Did the DT have a
particular technique in mind?

To be a bit more clear in what I'm after, is the WG leaning toward a)
using cookies that are returned to the CN (a la bu-3way), or b) partial
keys that are then used to authenticate the BU (a la bake/2).  If the
answer is option a, then I would imagine two separate cookies would be
sent, one over each path, and that both would be included in the final
BU.  Is that correct?  For option b, would the key generated by an
initial run of RR be reusable for BU refreshes if the node does not move
(I think that this is something Charlie wants).

In general, I'd like to get an idea of what the messages will look like
and exactly what information would need to be carried in each.

thanx in advance,
Bob

-- 
/****************************************************************

 Robert Chalmers
 UCSB Computer Science Doctoral Candidate
 Network and Multimedia Systems Lab (NMSL)

 "My heart is in the code, but my soul lies in the process"
 
 | [email-masked] || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 04 Mar 2002 18:38:12 -0800

Hi Bob!

> (I think that this is something Charlie wants).

Good question. Recently, there was some discussion on the related
topic. While doing RR, if we can establish a shared secret at CN,
then we can avoid, at least partially, the RR messages even when
the MN moves. For instance, with a shared secret, the MN does't have
to establish that it owns the Home Address (through the so-called HoA
RR tests) until the secret lifetime expires.

> and exactly what information would need to be carried in each.

I am also looking for the exact nature of the messages. The following are
additional likely candidates in these messages

- indication as to which particular Binding Authorization mechanism
   to be used. This is likely to be part of the BU itself
- piggybacking indication

Regards,

-Rajeev

---

From: Alexandru Petrescu<[email-masked]>
Date: 05 Mar 2002 13:41:53 +0100

Hi Robert,

> messages, 1a/b and 2a/b from the DT recommendation, should be

I can't seem to find the 1a/b... exchanges in the mails.  Could you
please post it here so we can discuss it easily.  Also, might be
useful to find a name for it: say "the generic RR exchange"?

From what I remember, these exchanges have been posted mainly to show
the complete scenarios that are possible to test the return
routability, in order to see where piggybacking can be done, etc..
But I think it will take more time to find exactly what messages are
necessary and what are redundant.

For example, since the first message goes CN->HA->MN, it might be
possible that a subsequent message MN->HA->CN might not need to go
through the HA again.  One way to do this is that HA inserts a token
into the first message transitting through it.  This mechanism would
prevent other verifications, though.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Mar 2002 14:54:56 +0200

Alexandru wrote:

> I can't seem to find the 1a/b... exchanges in the mails. 

See recommendation 4 in

  http://www.piuha.net/~jarkko/publications/mipv6/RRCGA_Mail.txt

We are working on the specifics of the messages.
Good names names for these would also be welcome,
right now I have:

   Binding Request (BR)
   Return Routability HoA Request (RRHR)
   Return Routability CoA Request (RRCR)
   Return Routability HoA Answer (RRHA)
   Return Routability CoA Answer (RRCA)
   Binding Update (BU)
   Binding Acknowledgement (BA)

But needless to say, I'm not very pleased
with the above names...

Jari

---

From: Alexandru Petrescu<[email-masked]>
Date: 05 Mar 2002 18:06:02 +0100

Jari Arkko <[email-masked]> writes:
> We are working on the specifics of the messages.  Good names names
> for these would also be welcome, right now I have:

Good naming schemes are indeed difficult to find :-)

Is this the intended name association?:

Return Routability HoA Request (RRHR)   1a. MN(HoA)--->HA--->CN     
Return Routability CoA Request (RRCR)   1b. MN(CoA)--------->CN     
Return Routability HoA Answer  (RRHA)   2a. CN-------->HA--->MN(HoA)
Binding Request                (BR)     2b. CN-------------->MN(CoA)
Return Routability CoA Answer  (RRCA)   3.  MN(CoA)--------->CN     

I'm not sure but I can't figure out a better association.  Please
enlighten.  I would propose:

Reverse Binding Warning        (RBW)    1a. MN(HoA)--->HA
                               (RBW)                   HA--->CN     
Binding Warning                (BW)     1b. MN(CoA)--------->CN     
Reverse Binding Request        (RBR)    2a. CN-------->HA
                               (RBR)                   HA--->MN(HoA)
Binding Request                (BR)     2b. CN-------------->MN(CoA)
RR Binding Update              (RR-BU)  3.  MN(CoA)--------->CN     

BW is from BAKE.  BU3WAY calls it Binding Update Request, in danger of
being abbreviated to Binding Request.  All 'reverse' messages transit
the HA, instead of going directly, like in "reverse tunnelling".  I
separated the reverse messages in two, but I doubt naming them is of
any use.

> The design team recommends both CoA and HoA tests to be performed

Which of the above messages are part of the CoA test and which are
part of the HoA test?  I'm asking because I'm trying to figure out
what each of these tests protects.

Thanks,

Alex

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 5 Mar 2002 19:16:06 +0200

The association is RRHR = 1a, RRCR = 1b, RRHA = 2a, RRCA = 2b,
and BU  = 3. BR and BA are then as they have always been.

RRHR and RRHA are part of the HoA test, RRCR and RRCA are
part of the CoA test, and BU draws everything together. Basically,
the -R messages are requests to start the tests, and don't contain
any real information. The -A messages are the real tests, and the
test ends with BU using data learned in the test messages.

How about

1a = HoA Test Init (HTI)
1b = CoA Test Init (CTI)
2a = HoA Test (HT)
2b = CoA Test (CT)
3 = BU

Jari

---

From: Alexandru Petrescu<[email-masked]>
Date: 05 Mar 2002 19:16:12 +0100

"Jari Arkko" <[email-masked]> writes:
> 1a = HoA Test Init (HTI)  1a. MN(HoA)--->HA--->CN     
> 1b = CoA Test Init (CTI)  1b. MN(CoA)--------->CN     
> 2a = HoA Test (HT)        2a. CN-------->HA--->MN(HoA)
> 2b = CoA Test (CT)        2b. CN-------------->MN(CoA)
> 3 = BU                    3.  MN(CoA)--------->CN     

Aha, that makes sense thanks.

Getting back to the recommendation:

> We also recommend additionally that these tests are made using
> separate requests in order to avoid reflection problems with the
> authorization protocol itself (a BU authorization request sent from
> the CoA should not be answered to the HoA).

In order to avoid the same reflection problems, the inverse is also
valid: a BU authorization request sent from the HoA should not be
answered to the CoA.  Right?

Alex

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 5 Mar 2002 20:19:11 +0200

> answered to the CoA.  Right?

Right.

Jari

---

From: Alexandru Petrescu<[email-masked]>
Date: 05 Mar 2002 19:30:37 +0100

"Jari Arkko" <[email-masked]> writes:
> > In order to avoid the same reflection problems, the inverse is
> > also valid: a BU authorization request sent from the HoA should
> > not be answered to the CoA.  Right?
> 
> Right.

But in that case I can be at home and flood HTI's to CN that will
flood the attacked MN with with CT's right?

Alex

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 5 Mar 2002 20:35:28 +0200

> flood the attacked MN with with CT's right?

Right, but that's no different from regular packets. The issue
is having a third address somewhere in the packet that redirects
you to another place, and bypasses possible ingress filtering
that was performed on your packets. As long as answers go
where requests came from, we are as safe as we can be in
the current internet.

Jari

---

From: Alexandru Petrescu<[email-masked]>
Date: 05 Mar 2002 20:06:29 +0100

"Jari Arkko" <[email-masked]> writes:
> Right, but that's no different from regular packets. The issue is
> having a third address somewhere in the packet that redirects you to
> another place, and bypasses possible ingress filtering that was
> performed on your packets. As long as answers go where requests came
> from, we are as safe as we can be in the current internet.

Aha, I see your above "first do no harm" point.  I fail to see,
however, the exact meaning probably because I don't know what exactly
goes into each RR message.

I was trying to say that the "reflection" thing is valid the other way
around too, and the mechanisms used to protect against it (I have rate
limiting in mind) should work for the first one too, this leading to
possibly not needing the HTI.

But I find it difficult to look at a protocol to which I can only make
assumptions of how it works.  I probably need to wait for when further
refinements come out.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 5 Mar 2002 20:19:38 +0100 (CET)

> where requests came from, we are as safe as we can be in

Hmm..

The response to a HTI would be a HT, and the response to a CTI would be
a CT.
Thus the response it always sent to the IP source address of the request/init.
Hence there is no reflection danger.

  Erik

---

From: Alexandru Petrescu<[email-masked]>
Date: 06 Mar 2002 10:09:55 +0100

> 3 = BU

I think I've already seen somewhere HTI short for Handoff Transfer
Initiate and CTI short for Context Transfer Initiate...

Alex