Subject: [Mobike] issue 12: interaction with other protocols doing RR

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Nov 2004 13:29:48 +0200

Jari Arkko writes:
> I would like to suggest that we do our own specific
> type of test, but allow same tests to be "reused" across
> protocols where this makes sense. That is, in MOBIKE
> we do our own test that verifies liveness of the address
> and that the peer is indeed still the same IKEv2
> node and has knowledge of some secret keying material.
> In addition, we add a note saying that the use of
> the results of this test may be possible in other
> protocol layers*.

How about, if we simply define the requirements for our tests, and say
that if those requirements are met by some other tests already done,
then tests inside MOBIKE can be skipped. And then we would of course
define what our tests provide, so others can skip their tests if your
tests fullfill their needs too. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Nov 2004 08:37:29 -0800

Jari,

> *) The example that comes to my mind is that since the
> mobile node - home agent interface in mobile IPv6 runs
> with IPsec, then the use of MOBIKE in that context
> would provide an RR test to home registrations. That
> does not exist in Mobile IPv6 at the moment, but if
> it were included then Mobile IPv6 home agent service
> could easier be offered to "unknown" peers. Currently
> "unknown" peers are only support as correspondent
> nodes.
>

IMHO, the lack of HA RR test in RFC 3775 is a residual vulnerability. RFC
3775 says that network operators should monitor their clients traffic and
cut them off if they try bombing. But how is an operator supposed to know
that? In the absence of any RR test, there's no way for the HA to know
whether the MN is at the care of address to which it is directing a video
stream, or whether its a bombing attack. This kind of insider attack is
still possible.

So I think this is an excellent idea. In fact, I think it should be used not
just with "unknown" peers but also with known clients of the HA.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Nov 2004 13:55:42 -0800

> just with "unknown" peers but also with known clients of the HA.

I would rather add an RR test to Mobile IP. It could be a
simple Mobility Header message probe protected by IPsec.
a couple of reasons.
1. I am not sure we are going to be using MOBIKE between
    a MN and HA (when they are already doing Mobile IPv6
    signaling. BU is your MOBIKE update message).
2. no need to have some kind of interaction between the
    IKE stack and the Mobile IPv6 stack

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Nov 2004 13:58:18 -0800

I think I pressed "send" before completing the second point

>    IKE stack and the Mobile IPv6 stack

no need to have some kind of interaction between the IKE
stack and the Mobile IPv6 stack for RR test.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 9 Nov 2004 14:10:44 -0800

Vijay,

> simple Mobility Header message probe protected by IPsec.

I've no objection to this, it might even be a better solution.

>     IKE stack and the Mobile IPv6 stack

I think it would be useful to compare the two solutions.

I have not read your IKEv2 for MIP draft, but I am interested to know if
some of the backdoor API changes in IPsec mentioned in RFC 3776 could be
removed if the HA and MN support MOBIKE. Do you think this would be
possible?

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Nov 2004 14:19:34 -0800

> some of the backdoor API changes in IPsec mentioned in RFC 3776 could be

nope. it is standard for anyone supporting PF_KEY.

> removed if the HA and MN support MOBIKE. Do you think this would be

it would be a bad idea if you the MN has to send a MOBIKE
update in addition to binding update during a handoff. we should
try to do it one message. there is already a secured message for
doing the update (a Binding Update).

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Tue, 09 Nov 2004 23:32:09 +0100

In your previous mail you wrote:

   I would rather add an RR test to Mobile IP.

=> I don't understand this necessity to even more damage Mobile IPv6.
Perhaps it is not yet in trouble?

   It could be a

=> it simply costs a RTT for a second order threat.

   a couple of reasons.

=> we are going to use either MOBIKE between a mobile VPN client
and SG, or Mobile IPv6 between a MN and HA.

=> and the K flag?

Regards

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Nov 2004 14:48:42 -0800

> Perhaps it is not yet in trouble?

I agree with you. if an RR test is needed for Mobile IP, we can
develop it in Mobile IPv6. I dont see MOBIKE's RR test used by
Mobile IPv6.

> and SG, or Mobile IPv6 between a MN and HA.

agree completely.

>        IKE stack and the Mobile IPv6 stack

right. we dont need it for an RR test.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Nov 2004 13:36:13 +0200

>    IKE stack and the Mobile IPv6 stack

Yes, this is indeed another (and pretty good) alternative!
But stating in the MOBIKE document that the results of
the RR test are usable by "applications" leaves this
choice to you (or the MIP6 WG).

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Wed, 10 Nov 2004 14:46:10 +0100

=> Jak, it seems you missed an important point: Mobile IPv6 and
MOBIKE are two *incompatible* solutions for the same problem (if
you restrict things to IPv6 mobility without optimization).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 10 Nov 2004 15:18:23 +0100

=> perhaps we don't speak about the same thing: I argue the RR test
is not necessary (and as it has a cost is only a burden we should not
add) for mobile IPv4/IPv6. And it should be optional for MOBIKE,
i.e., it should be performed by the SG of a mobile VPN only if
it is in its policy. IMHO the only thing we should talk about is
what to put in the default policy (perform or not perform an RR test
by default?)

   agree completely.
   
=> so the mobile IP part of this discussion is clearly outside the
scope of both the WG and the list.
   
Regards

---

From: "James Kempf" <[email-masked]>
Date: Wed, 10 Nov 2004 07:34:42 -0800

Um, thanx Francis. Your application of a baseball bat has driven the point
home. :-)

            jak

----- Original Message ----- 
From: "Francis Dupont" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]>; "MOBIKE Mailing List"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, November 10, 2004 5:46 AM
Subject: Re: [Mobike] issue 12: interaction with other protocols doing RR

---

From: Jari Arkko <[email-masked]>
Date: Mon, 29 Nov 2004 16:45:46 +0200

We had a proposal where the results of MOBIKE RR
test could be used by other protocols, if deemed
useful by the designers of these other protocols.
There seems to be general support for this proposal.

We also had a discussion about whether this would
make sense in the Mobile IPv6 space; different
opinions and technical alternatives were offered.
That's OK, however, because we don't get to decide
this part of the problem in WG.

But we can now move forward with the original issue.
Here's my proposalon what the design draft should
say about the matter:

Replace the current text

    MOBIKE might also want to export the information it has done the
    return routability checks to the other modules, like Mobile IP, so
    Mobile IP does not need to do return routability checks again, if it
    is satisfied with the level of checks done by the MOBIKE.

with this new Section:

X. Employing MOBIKE results in other protocols

    If MOBIKE has learned about new locations or verified
    the validity of an address through a return routability test,
    can this information be useful for other protocols?

    When considering the basic MOBIKE VPN scenario, the answer is
    no. Transport and application layer protocols running inside
    the VPN tunnel have no consideration about the outer addresses
    or their status.

    Similarly, IP layer tunnel termination at a gateway rather
    than a host endpoint limits the "other protocols" that could
    be informed -- all application protocols at the other side
    are running in a node that is unaware of IPsec, IKE, or MOBIKE.

    However, it is conceivable that future uses or extensions of
    MOBIKE make such information distribution useful. For instance,
    if transport mode MOBIKE and SCTP were made to work together, it
    would likely be useful for SCTP to learn about the new addresses
    at the same time as MOBIKE learns them. Similarly, various IP layer
    mechanisms might make use of the fact that a return routability
    test of a specific type has already been performed. However, in
    all of these cases careful consideration should be applied.
    This consideration should answer to questions such as whether other
    alternative sources exist for the information, whether dependencies
    are created between parts that prior to this had no depedencies, and
    what the impacts in terms of number of messages or latency are.

    Reference [draft-crocker-celp-00.txt] discussed the use of
    common locator information pools in IPv6 multihoming context;
    it assumed that both transport and IP layer solutions would be
    used for providing multihoming, and that it would be beneficial
    for different protocols to coordinate their results in some manner,
    for instance by sharing experienced throughput information for
    address pairs. This may apply to MOBIKE as well, assuming it co-exists
    with non-IPsec protocols that are faced with the same multiaddressing
    choices.

    Nevertheless, all of this is outside the scope of current MOBIKE
    base protocol design and will be addressed in future work.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Mon, 29 Nov 2004 09:25:23 -0800

This text looks fine to me.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 29 Nov 2004 10:23:30 -0800

sounds fine to me.

Vijay