Subject: [monet][mobile-ip] Supporting multiple Nodes behind one CoA with CoTI/CoT

From: Greg Daley <[email-masked]>
Date: Thu, 05 Sep 2002 16:11:08 +1000

Sorry about the long cross post [NEMO/monet,Mobile IP].

I think this idea is relevant to both lists.
If you have responses only relevant to one,
please edit the destination.

I've been looking at a number of situations where
e-2-e security associations have to be created
for nodes which do not have a unique care of address.

What I mean by this is that there is a single node
attached to the internet, which has been granted
trust by an MN to receive packets on its behalf, and
forward them on to the MN at another address.

This agent provides a single IP address for some or
all of the MNs which it services.

This is the case in certain Localized Mobility Managent
(LMM) systems.
HMIPv6 Extended Mode and also NEMO Mobile
Routers may be particularly affected.

In these systems end-to-end communication is typically
provided by ensuring that all packets to the MN are
tunnelled via the HA or received from CN's with Type 2
Routing Headers.  In certain situations, some
reverse tunnelling from the MN to the agent is
allowed in order that  the MN may send packets from
the agent's address.

Therefore in most cases, packets can be received
at the MN, which can be used for generating an
end-to-end SA or other trust mechanism.

The issue which occurs is that when an MN attempts
to perform a CoTI/CoT exchange, even if the MN can
send the CoTI message from the Agent's address,
there is no information which may be used by the
agent to send the responding CoT message to the MN,
since the CoT packet has only a destination IP
address, which is the shared CoA address at the LMM
agent.

I think that this is principly because the CoTI
message doesn't have a Home Address option, in order
to guarantee that the CoA which is indicated in the
message is correctly interpreted by the CN.

Please indicate if you know of another reason for this.

In any case, if the CN was able to send the response
CoT packet with an RH2 containing the Home Address of
the MN,it would allow the packet to be received
for the MN at an intervening agent, and forwarded or
tunnelled to the MN.

MN's receiving a CoT directly or from such an agent may
substitute the Home Address in the RH2 for the address
to which the packet was sent (dependent on implementation),
but it would be easy to identify the associated CoTI and
CoA by use of the CoT Cookie sent in the CoTI and CoT
(which the MN will track).

It is a current requirement that MNs receiving
RH2 not process the packet unless it owns the address
contained in it.  In the case of the agents mentioned,
the association they have with the MN would be
sufficient to decide whether to send the packet to
the MN.

In this fashion, I don't think there is a significant
security issue in the reception of such packets at an
MN or LMM agent.

Please tell me if you see this to be incorrect.

On the CN, if it were made aware of the requirement to
send the RH2, there would be no persistent state kept
regarding the home address which the packet is sent.
It could easily be copied from a received CoTI and
forgotten about.

If the Home address was sent in a (new) routing address
mobility option, the CN could ignore it, and send a
standard CoT  to the CoA.  This may break the CoA
processing  on the LMM agent though, since it may not
find  a destination node (and will pass up the stack to
be processed by the LMM agent).

Another alternative is to use a mobility header type
which explicitly supports CoTI with destination. Any
system understanding the header would have to understand
the routing address mobility option.

I'm probably thinking that the second idea is better,
since ICMPv6 error messages could be generated to the
CoA (at the LMM agent), which would act similarly to
the "packet too big" handling which already exists
for tunnels, being sent back to the originating MN.

Other than that, I don't see any significant differences
with RR in MIPv6 D18 for the MN or CN, nor can I see any
significant security implications other than those
which RR is susceptible to.

Once again, please tell me if you see this differently.

If the mechanism is valid, then it would be
straightforward to for CN's to validate the
(Shared) CoA of MN's for the purpose of route
optimization in Local Mobility Managed networks,
and NEMOs using end-to-end Return Routability tests.

Greg Daley
Centre for Telecommunications and Information Engineering
Monash University

---

From: "Pascal Thubert" <[email-masked]>
Date: Thu, 5 Sep 2002 09:46:09 +0200

Hi Greg:

Seems that the RR test is broken for your cases since it's meant to ensure that
the 2 addresses are collocated. I started a discussion on MIP and one on Nemo on
the subject.

From your proposal, I just wonder who sends the CoTi in the first place. If
that's the MN, then it must know the (LMM|MR) CoA, which implies added control
traffic and an invalid source address that the (LMM|MR) should not let through.
On the other hand, if the RR test is performed between the (LMM|MR) and the CN,
the (LMM|MR) should issue the HoTi and keep the response HoT for itself though
it's sent to the MN Home Address. Bad as it is, it may not work at all in Nemo
multi-homing.

In the other hand, what's the use of the CoT, and do we need the CareOf address
as part of the e2e SA at all? For MIP, this causes the RR test to be performed
each time the MN changes attachment and delays the bind process. For Nemo, it
prevents the RR test compatibility, and places RO in a hazardous position.
Jari's answer was a case of bombing attack that seems theoretically possible.
Please refer to the exchange on july 1st 2002, on the "[mobile-ip] CoT " thread.
I'm not convinced yet whether preventing that bombing attack is worth delaying
all valid attachments.

On another thread, I tried to introduce a negotiation at RR test time. Please
refer to the exchange on july 1st 2002,  on the "[mobile-ip] Re: summary of HAO,
BE processing discussion" thread. If CoT becomes optional, this is an other case
where the negotiation capability could be useful.

BTW, If the CoA is not part of the shared secret between the MN and the CN, then
the MN can use any of the multiple CoA you're talking about without wondering
the SA it should use. This is important if the MN does not know the MR's CoA,
which may vary over time...

What do you think?

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Greg Daley
Sent: Thursday, September 05, 2002 8:11 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [monet] [monet][mobile-ip] Supporting multiple Nodes behind one CoA
with CoTI/CoT

Greg Daley

---

From: Jari Arkko <[email-masked]>
Date: Thu, 05 Sep 2002 17:05:45 +0300

> Please indicate if you know of another reason for this.

This sounds a bit like the NAT device problem: it is
easy to pass a packet through and change the addresses,
but how do know where to route the incoming response
packet? Traditionally, IPv4 identifier field, TCP/UDP
port numbers, etc. have been used to accomplish this.

In your model, is it possible for the MN to use its
CoA directly without HAO, e.g. for a short duration
DNS query or an ICMP ping? If yes, how will the MR/LMM
route back the packets?

But yes, HAO could be used as an indicator for routing
the response to the right MN. Other alternatives include
the mobile cookie, but it would have to be a dynamically
cached item.

> Please tell me if you see this to be incorrect.

I think your analysis is more or less correct. Note
that we in general don't allow HAOs to appear in
communications to the CN until a binding is established --
except for the Binding Update which is handled as a special
case. It would be possible to make a similar exception
for the CoT message as well, if desired.

Also, the current independence between HoT and CoT makes
it possible to reuse one CoT response for multiple home
addresses. If adding the HAO to CoT would also change the
rules for calculating the cookies, then this would change.

> be processed by the LMM agent).

This alternative may not work unless the CN knows somehow
that it must copy the new option back to the answer.

> the routing address mobility option.

This would work.

> for tunnels, being sent back to the originating MN.

Right, and getting the ICMP is similar to finding a
too old IPv6 node that doesn't support even basic RO
yet.

> which RR is susceptible to.

Pascal made some good questions on who is going to send
the CoT and how this is made possible in the practical
sense. I don't have ideas on how to make it work when the
MR/LMM is the sender and multihoming is in involved. If the
MN sends the packet, then I suppose it can use a local
address under the MR/LMM, and then MR/LMM changes that
to the shared CoA?

Jari

---

From: Greg Daley <[email-masked]>
Date: Fri, 06 Sep 2002 09:59:06 +1000

Hi Pascal,

Thanks for the response.
I think I'll have to break up the response
into two threads, one for each group.

As one WG member has indicated, things get complicated
very quickly when NEMO terminology is being used
in mobile-ip.

> From your proposal, I just wonder who sends the CoTi in the
 > first place. If that's the MN, then it must know the
 > (LMM|MR) CoA, which implies added control traffic and an
 > invalid source address that the (LMM|MR) should not let through.

The main goal of receiving the CoT at the MN is to
get end-to-end. The assumption is that the LMM
will allow the MN to send the CoTI through a reverse tunnel.

It would be simple to provide a static filter on the
LMM agent which only allows CoTI's out of the tunnel.

> On the other hand, if the RR test is performed between the
 > (LMM|MR) and the CN, the (LMM|MR) should issue the HoTi and
 > keep the response HoT for itself though it's sent to the MN
 > Home Address. Bad as it is, it may not work at all in Nemo
 > multi-homing.
>
> In the other hand, what's the use of the CoT, and do we need
 > the CareOf address as part of the e2e SA at all? For MIP,
> this causes the RR test to be performed each time the MN
 > changes attachment and delays the bind process. For Nemo, it
> I'm not convinced yet whether preventing that bombing attack
 > is worth delaying all valid attachments.

Some indication that the MN is allowed to use the CoA is
important. Whether that may be handled by a delegated node
LMM on behalf of the MN is up to the community to decide

for example: MN asks LMM Agent to do a CoTI on the MN's behalf.
              MN gives LMM Agent CoT Cookie.
              LMM agent sends CoTI to CN, with CoT Cookie,
              CN sends CoT to LMM agent, with CoT cookie.
              LMM agent uses CoT cookie to look up MN which requested
              LMM passes CoT Information back to MN with CoT cookie.

advantages:   no modification to CN's
disadvantages:relies on LMM agent to proxy.

Since the LMM agent is already trusted to route packets to the
MN, I don't see a problem with this, but I didn't want to get
shouted at by people who do :)

> On another thread, I tried to introduce a negotiation at
 > RR test time. Please refer to the exchange on july 1st
 > 2002,  on the "[mobile-ip] Re: summary of HAO, BE processing
 > discussion" thread. If CoT becomes optional, this is an other
 > case where the negotiation capability could be useful.
> 
> BTW, If the CoA is not part of the shared secret between the
 > MN and the CN, then the MN can use any of the multiple
 > CoA you're talking about without wondering the SA it should use.
 > This is important if the MN does not know the MR's CoA,

I'm pretty sure that I like feedback from the CN if it is
unable or unwilling to perform portions of RO. Having only
the HoTI/HoT could indicate that triangular routing is
available with HoA option processing, which is better than
reverse tunnelling.

This would provide a completeness case for when a CoT is
invalidated (for example due to timeout or incomplete CoT),
but the HoT is still valid, and the CN is still able to
receive HoA option packets.

Greg Daley