Subject: [mobile-ip] I-D ACTION:draft-bagnulo-mobileip-unreachable-hoa-00.txt

From: [email-masked]
Date: Tue, 03 Jun 2003 07:47:19 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Preserving MIPv6 communications when the HoA becomes 
                          unreachable
	Author(s)	: M. Bagnulo et al.
	Filename	: draft-bagnulo-mobileip-unreachable-hoa-00.txt
	Pages		: 12
	Date		: 2003-6-2
	
This note proposes a modification to the MIPv6 specification in order
to allow the preservation of established communications when the path
between the MN and the CN through the HoA becomes unavailable.  The
proposed modification essentially consists on allowing the extension
of BCE lifetime upon the reception of ICMP Destination Unreachable
message as reply to a Binding Refresh Request (BRR) message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bagnulo-mobileip-unreachable-hoa-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-bagnulo-mobileip-unreachable-hoa-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-bagnulo-mobileip-unreachable-hoa-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 3 Jun 2003 11:27:20 -0700

This seems like a hack and not a behavior that you would want to
recommend in a RFC.
Route Optimization is supposed to be an optimization, the fall-back and
basic support for mobility is provided by tunneling through the HA. When
the HA is not available, IMO it does not make sense to continue route
optimization.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Tuesday, June 03, 2003 4:47 AM
> To: IETF-Announce:
> Cc: [email-masked]
> Subject: [mobile-ip] I-D 
> ACTION:draft-bagnulo-mobileip-unreachable-hoa-00.txt
> 
> 
> This note proposes a modification to the MIPv6 specification 
> in order to allow the preservation of established 
> communications when the path between the MN and the CN 
> through the HoA becomes unavailable.  The proposed 
> modification essentially consists on allowing the extension 
> of BCE lifetime upon the reception of ICMP Destination 
> Unreachable message as reply to a Binding Refresh Request 
> (BRR) message.
> 

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
	"get draft-bagnulo-mobileip-unreachable-hoa-00.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-bagnulo-mobileip-unreachable-hoa-00.txt".
	
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.486 / Virus Database: 284 - Release Date: 5/29/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.486 / Virus Database: 284 - Release Date: 5/29/2003

---

From: marcelo bagnulo <[email-masked]>
Date: 04 Jun 2003 11:30:10 +0200

Hi Ed,

Thanks for reading the ID.

A few comments below...

> the HA is not available, IMO it does not make sense to continue route

When RO is being used, the communication flows directly between the MN
and the CN without using the HA. However, because of the need to perform
the RR procedure, the communication is susceptible not only to failures
along the path that is actually used to carry packets between the CN and
the MN but it is also susceptible to failures in the path between the MN
and the HA, in the path between the HA and the CN, and in the HA. IMHO
this is not a desirable feature, and i think that the solution would
benefit if we can make it more robust, especially to failures not
affecting the path that it is currently being used (this would only make
it as robust as a normal internet communication). 

Why would you want to keep additional points of failure if you can avoid
them? IMHO it is interesting to explore that possibility. 

Regards, marcelo   

-- 
marcelo bagnulo <[email-masked]>
uc3m

---

From: Greg Daley <[email-masked]>
Date: Thu, 05 Jun 2003 09:12:08 +1000

Hi Marcelo,

just a few questions.

> them? IMHO it is interesting to explore that possibility. 

It seems that the draft is about loss of Home Address,
that is, it is a loss of being able to prove identity.
There are already systems which allow alternative identities
(key based) to be established in the case that mobile nodes
require robustness against HoA unreachability.

I guess that these could be used to ensure that connectivity is
maintained without causing further security hassles.

Additionally, I would assume that HoA loss means that all
possible home agents on a network are unavailable.
In many cases, this function will be available from multiple routers
on a link (possibly with redundant connection to the Internet).
In the rare case that all of these routers are unreachable,
it may be valid to cause the MN to re-establish CN communications
after dynamically retrieveing a home address from the visited link.

I really don't think that there is a case for this today.
(If you can point me to some literature, it may help me to
understand your point)

Greg

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 04 Jun 2003 17:36:22 -0700

Hello Ed,

>>the HA is not available, IMO it does not make sense to continue route
I don't believe this model.  If the home agent dies, and the mobile node and
the correspondent can still communicate, why stop?  What if they were on
exactly the same subnet?

Regards,
Charlie P.,

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 4 Jun 2003 18:25:07 -0700

Charlie -

> I don't believe this model.  If the home agent dies, and the 
> mobile node and the correspondent can still communicate, why 
> stop?  What if they were on exactly the same subnet?

>From this draft:
"  The BCE lifetime can only be renewed 60 times, limiting to 3 hours
   the maximum time that an BCE entry can be valid without performing
   the RR procedure."

That is (IMHO) an awfully long time to allow the CN to continue to
refresh and reuse this binding in the absence of any positive
confirmation from the HA that this is actually a valid mobility binding.
The fact that the HoT/HoTI exchange is tunneled through the HA provides
some form of validation/authentication that the MN is actually who he is
claiming to be.

W/ regards to if the MN and the CN are on the same subnet, well if the
MN is at home then it should have already deregistered its mobility
bindings. If it is on a foreign link, then it can use one of its CoAs on
the foreign link (w/out using its home address) to directly communicate
with the CN (for short duration connections).

I kind of see what you are talking about, however. I guess it is a bad
thing for the HA or more specifically the network path to the MN's home
network to be a potential point-of-failure, especially when the MN can
be reached through the CoA. So, I guess my main objection to this is it
allows the binding to be prolonged too long (3 hours is a long time) in
the absence of confirmation to the CN that the MN's HA and home network
is still reachable.

Thanks.
- Ed

---

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 04 Jun 2003 19:08:17 -0700

Hello Ed,

Three hours is no problem at all for preconfigured or
"other-"configured security associations between the
mobile node and correspondent node, which will be
used whether or not it's in the base specification.
I really think it was a terribly bad decision based on
impossible logic to have deleted this from the base
specification.  Then the only reason to place this
additional restriction is in case someone is on a
vendetta against alternative configuration of security
associations between correspondent nodes and
mobile nodes.

Regards,
Charlie P.

---

From: marcelo bagnulo <[email-masked]>
Date: 05 Jun 2003 12:04:13 +0200

Hi Greg

On Thu, 2003-06-05 at 01:12, Greg Daley wrote:
[...]

> require robustness against HoA unreachability.

Could you give a pointer to the documents? Thanks

> (If you can point me to some literature, it may help me to

Currently, MIPv6 communication are terminated if:
- a failure in the path between the CN and the HA occurs 
- a failure in the path between the MN and the HA occurs
- a failure in the HA occurs

I do agree with you that HA can be redundant and that HA internet access
can also be redundant. However, there is a part between the HA and the
CN that it is not under the HA's administrative domain so there no way
to make sure that it will be fault tolerant, that same goes for a part
of the path between the MN visited network and the HA.
A simple case is the one that Charlie P. pointed out, where the MN and
the CN are on the same subnet and the visited subnet's Internet access
fails, leaving both MN and CN unreachable form the HA. I guess that more
similar scenarios can be conceived.

The point is why do you have to keep additional points of failure if
they are not strictly needed?

Thanks, marcelo

---

From: marcelo bagnulo <[email-masked]>
Date: 05 Jun 2003 14:34:42 +0200

On Thu, 2003-06-05 at 03:25, Ed Remmell wrote:
[...]
> be reached through the CoA.

Great!

>  So, I guess my main objection to this is it

I do agree that this should be carefully addressed since the security
issues are critical.
Do you have in mind a concrete attack that can be performed that has not
been considered in the proposal?

Thanks, marcelo

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 5 Jun 2003 12:02:36 -0700

> I do agree that this should be carefully addressed since the 
> security issues are critical. Do you have in mind a concrete 
> attack that can be performed that has not been considered in 
> the proposal?

Not specifically.

Thanks.
- Ed

---

---

From: Greg Daley <[email-masked]>
Date: Fri, 06 Jun 2003 10:04:52 +1000

Hi Marcelo,

> Could you give a pointer to the documents? Thanks

the first I can think of would be use of CGA:
draft-aura-cga-00.txt describes this topic generally,
and has a reference to a MIPv6 application of this.

It would be easy to relate an identity which had been established
on a previous subnet's CoA or home address to one related to the
new CoA.     Unfortunately, CGA is encumbered technology.

For critical communications, it may be necessary to have
proof of identity from a previously negotiated security
association.  I know that IKE or other IPSec SA creation
mechanisms are not generally valid for CN communications,
but if we require robust communications to a server it may
be valid to utilize this mechanism.

We're talking about a problem here which cannot be solved
by the IP routing infrastructure, so it is certainly severe.

> similar scenarios can be conceived.

The simple case mentioned may be problematic in any case using
RR.  Having a device on the path (or on the same link) as the
CN which can snoop and replay credentials exchanged by the MN and
CN in their RR tests is a security hole. Your  proposal only
makes this more difficult to plug on the local link case.

In the case where the MN and CN are on the same subnet, RR is
certainly not required to prove location (SEND can do this),
just the identity of the MN.  Once again, if the MN is able to
pre-establish an SA (or at least provide a set of credentials
for later use in BUs) this issue goes away.

> they are not strictly needed?

I agree with you in principle, but I don't like the
method (yet).

I am interested in the outcome of this work, though.

Greg

---

From: marcelo bagnulo <[email-masked]>
Date: 06 Jun 2003 17:49:50 +0200

> >>that is, it is a loss of being able to prove identity.

Returning to a previous posting....

I guess that there is a precision that is to be made. That is that the
MN has already proved its identity to the MN, because it is assumed that
the RR procedure has already been performed successfully at least once.
this implies that a BCE exists when the HoA becomes unreachable. the
problem considered is how to keep the BCE valid safely.
BCE lifetime is limited as a mechanism to limit time shifting attacks, i
mean the goal is not to prevent impersonation. The goal is imposing the
presence of the attacker along the path in order to launch the attack.

So the goal of the proposed draft is to extend the BCE lifetime when the
HoA is unreachable and preserve the current level of security. It is not
the goal of the draft to improve the current security of MIPv6.

> be valid to utilize this mechanism.

I guess that there are multiple mechanisms that can be used to have an
extended BCE lifetime. Charlie P. have mentioned in a previous posting
the case where a SA exists between the CN and the MN, i guess that you
are thinking in something similar. 

I would say that there are multiple different scenarios that have to be
considered and that different mechanisms to preserve established
connections through HoA unreachability will apply in those scenarios. 

For instance, Charlie P. have mentioned in a previous posting the case
where a SA exists between the CN and the MN, i guess that you are
thinking in something similar above. This scenario essentially assumes
some sort of trust between the CN and the MN so that the SA can be
created. Is this correct?

A different scenario is the one considered in the draft, where no SA is
required, it is just an extension to the RR procedure. this mechanism
would be less secure, but it would be suitable for more general
situations, since nothing is assumed about the relation between the CN
and the MN.

I guess that both scenarios make sense and a more general approach would
be to provide an optimization to MIPv6 to preserve established
connections when the HoA is unreachable in different scenarios. Would
this make sense to you? 

> by the IP routing infrastructure, so it is certainly severe.

Depends what scenario you are considering (see above)

> makes this more difficult to plug on the local link case.

As i mentioned above, it is a non-goal of the proposal to improve MIPv6
security, just to extend BCE lifetime preserving the current security
level.

> I agree with you in principle, but I don't like the

I see what you mean...

Perhaps if i describe the rationale of the mechanism in a few words,
this would improve a bit...

Limited BCE lifetime limits time shifting attacks by imposing the
presence of the attacker along the path, in order to reply to the RR
procedure.

However, if the path through the HA becomes unavailable, the RR
procedure fails, because the MN can not be reached through the HA.

The idea is then that the BCE lifetime can be extended if there is some
reply from a device along the path through the HA. 
The CN then sends a BRR message that carries a cookie, and it extends
the BCE lifetime if the replied message contains the initial cookie.
This imposes that an attacker has to be along the path to intercept the
message and obtain the cookie in order to extend the BCE (and continue
with the attack)

So the attacker has to be on the path, so time shifting attacks are
limited.

> I am interested in the outcome of this work, though.

Thanks,

Regards, marcelo

---

From: Greg Daley <[email-masked]>
Date: Mon, 09 Jun 2003 13:15:16 +1000

G'Day Marcelo,

> the goal of the draft to improve the current security of MIPv6.

Your point is taken.

After a more careful re-reading of your draft, I see that
the reception of a portion of the BRR (in a destination
unreachable message) is essential to proving that the
respondent router is on the path.

It is worth noting though, that destination unreachable
responses (and other ICMP errors) are rate limited on
routers.

> created. Is this correct?

Yes, trust is essential for the CN to decide to redirect
its traffic flow to a potential CoA.  RR is one mechanism
for creating that trust or Security Association (just for the
purpose of Binding Cache modification).

> situations, since nothing is assumed about the relation between the CN

I think that I'm seeing your point of view now,
but still have reservations about the 'less secure' nature
of the method.

> connections when the HoA is unreachable in different scenarios. Would

Certainly this makes sense.  I will have a think about
the relationship of your method to existing HoTI/HoT.
At this stage, I would still be reluctant to use this
as a default method for all communications, though.

Your description below helped significantly.

> So the attacker has to be on the path, so time shifting attacks are

Once again, I will look into this.

Thanks for your response,

Greg

---

From: marcelo bagnulo <[email-masked]>
Date: 09 Jun 2003 17:56:49 +0200

[...]

> purpose of Binding Cache modification).

Is there any other mechanisms besides RR procedure  currently supported
in the MIPv6 spec? 

Is the case where a SA exists between the MN and CN node supported by
the current MIPv6 spec? I mean, if a SA exists between them, can they
just skip the RR procedure?

> but still have reservations about the 'less secure' nature

This is the point, that why it needs further discussion, in order to
explore possible weaknesses.

> as a default method for all communications, though.

The idea is that the normal RR procedure is applied as long as the HA is
available. The proposed method is an optimization in case that the HA is
unreachable. The new mechanism in not intended to substitute the current
RR procedure.

[...]
> Once again, I will look into this.

Thank you very much, regards, marcelo

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 09 Jun 2003 21:08:22 +0300

Greg, Marcelo,

> just skip the RR procedure?

I don't remember what became written into the spec, but the
idea in the RO security DT was that if there is an SA between
the MN and CN, and if that SA is somehow based on known identities
(implying some level of trust) and not just an anonymous one,
the hosts MAY skip the HoT/BU test.  However, they must still
perform the CoT/BU test lest there would be a flooding attack.

> explore possible weaknesses.

Marcelo and I has an off-list chat of the procedure already
before he submitted the draft.  Based on my 5 second analysis,
the method seems to be roughly as secure as basic RR.  However,
I disagree with Marcelo about how long you could use the method
to extend a BCE lifetime while the HA is unavailable.  My personal
feeling, based on intuition and not any analysis, is that maybe
30 minutes would be a good maximum value.  If I remember correctly,
Marcelo suggests 3 hours.  IMHO, that would be far too long.

--Pekka Nikander

---

From: marcelo bagnulo <[email-masked]>
Date: 10 Jun 2003 12:24:05 +0200

Hi Pekka,

> perform the CoT/BU test lest there would be a flooding attack.

I guess that this behavior would allow that communications are preserved
when the HA becomes unreachable. However, the only authorization
mechanisms for BU to CN that i could find in a quick scan to the spec is
the RR. Other authorization mechanisms are left as future extensions.

> Marcelo suggests 3 hours.  IMHO, that would be far too long.

I think it is worth pointing that the purpose of setting a maximum time
for the BCE lifetime can be extended using the proposed mechanism is
essentially different than the the purpose of the the maximum BCE
lifetime in the following sense: 
If i understand correctly, the lifetime of BCEs that have authorized
using the RR procedure is set to 7 minutes in order to limit the time
that the communication is exposed to a time shifting attack. I mean,
there is a concrete attack that can be performed, and setting the
maximum BCE lifetime to 7 minutes limits its impact.
However, the purpose of defining a maximum time that BCE lifetime can be
extended using the proposed mechanism is not the prevention of a
concrete attack (at this point). As i understand it, this limitation is
more like a safe net, in order to protect from undetected attacks.
I think that this is wise think to do, however, this proposal is about
preserving established communications, so the longer we can preserve
them, the better.
The trade-off then is time that communications are preserved versus
protection from undetected attacks.

I think that we should be able to better asses the risks involved when
the security issues and possible vulnerabilities have been more
discussed.

Thanks, marcelo

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 10 Jun 2003 16:18:14 +0300

> more like a safe net, in order to protect from undetected attacks.

Agreed.

> preserving established communications, so the longer we can preserve

Yes, given the trade-offs, which you pointed out next (now below).

> the security issues and possible vulnerabilities have been more

Agreed.

--Pekka