Subject: RE: [nemo] Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 10 May 2004 13:08:54 +0200

Hi Seongho,

I have some questions about this draft.

1. In section 5.1 Neighbor MRs Discovery is stated that neighbors discovery
is based in RA messages. My question is how does the solution works when the
multiple MRs are not all connected to the same link, but there are routers
between them? This implies that MR1 cannot hear RA messages from MR2.

For instance:

     |                 |
    MR                 MR
     |                 |
   ----------Router-------

2. In the same section it is stated that from the neighbor discovery
process, MR1 can discover all the required data from MR2, such as HoA, CoA
and MNP. My question is how does MR1 discovers the CoA of MR2? i mean, as i
understand it, RA messages does not contain such information, since the
egress interface belongs to another link.

3. About the usage of RR to authenticate a MR presented in section 5.2
First of all, i am not sure that i understand why the RR procedure is
suitable to perform this particular authentication. I mean, the RR check
verifies the collocation of a HoA and a CoA (or two addresses if you would).
But in this case, i would say that you need to verify more than just that. I
mean, using only the RR check, any device with both an ingress and egress
interface can claim to be a MR of the NEMO and the RR check will succeed.
For instance an attacker can simply join the nemo and if he has a wireless
interface connecting to the internet, it can claim to be a MR. Wouldn't be
necessary additional verifications, like an list of authorized MR?, and once
that you have that list, what do you need to perform the RR check for?
Additionally, using the RR check may have some issues, since for instance
the BCE lifetime of binding validated using RR check are limited to 7
minutes. This implies that you have to perform the RR check every 7 minutes.
But what happens if the MR is no longer available (which as far as i
understand i one of your goals)

4. Finally, once that the HA is using an alternative MR, how do you manage
to exchange signaling between them? I mean, BU messages and other signaling
must be authenticated using IPSec, but the HA and the new MR don't have an
IPSec SA between them, so i don't see how the will be able to exchange
signaling, for instance when there is a movement and a new CoA has to be
announced from the MR to the HA.

Regards, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En nombre de Seongho
> Cho
> Enviado el: martes, 27 de abril de 2004 3:41
> Para: [email-masked]
> Asunto: [nemo] Fw: I-D ACTION:draft-cho-nemo-mr-registration-00.txt
>
>
>  Hi forks,
>
>  To inform you that we have submitted a new I-D on neighbor MR
> authentication
> & registration mechanism for multihomed mobile networks.
> We propose a dynamic MR registration solution without extra
> signaling message,
> and hope that this I-D will initiate some discussions on this topic.
>
>  Thanks.
>
>  Bests,
>  Seongho
>
> ----- Forwarded message from [email-masked] -----
>
> To: [email-masked]
> From: [email-masked]
> Subject: I-D ACTION:draft-cho-nemo-mr-registration-00.txt
> Date: Mon, 26 Apr 2004 15:26:20 -0400
> Errors-To: [email-masked]
> X-BeenThere: [email-masked]
> X-Mailman-Version: 2.0.12
> Precedence: bulk
> Reply-To: [email-masked]
> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
> 	<mailto:[email-masked]?subject=unsubscribe>
> List-Id: <i-d-announce.ietf.org>
> List-Post: <mailto:[email-masked]>
> List-Help: <mailto:[email-masked]?subject=help>
> List-Subscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
> 	<mailto:[email-masked]?subject=subscribe>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>
> 	Title		: Neighbor MR Authentication and
> Registration Mechanism
> 			  in Multihomed Mobile Networks
> 	Author(s)	: S. Cho, et al.
> 	Filename	: draft-cho-nemo-mr-registration-00.txt
> 	Pages		: 12
> 	Date		: 2004-4-26
>
> In multihomed mobile networks, multiple Mobile Routers can be
>    deployed to provide fault recovery or load sharing. Also, each Mobile
>    Router (MR) can have a bi-directional tunnel with its own Home Agent
>    (HA). In this multihomed mobile network scenario, the neighbor root
>    MR can replace or share the operation of another MR. Therefore, MRs
>    should cooperate with each other to provide session continuity or
>    load sharing. We present an authentication and registration mechanism
>    without introducing extra signaling messages. Using the Return
>    Routability procedure of Mobile IPv6 and the Binding Update message
>    with the neighbor MR registration option, the MR can authenticate and
>    register the neighbor MR to its own HA. And the HA can use this
>    registered neighbor MR information to provide fault recovery or load
>    sharing.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-cho-nemo-mr-registration-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the
> body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> 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-cho-nemo-mr-registration-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-cho-nemo-mr-registration-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.
>
>
>
> ----- End forwarded message -----
>
>

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 10 May 2004 13:08:54 +0200

Hi Seongho,

For instance:

     |                 |
    MR                 MR
     |                 |
   ----------Router-------

Regards, marcelo

---

From: Seongho Cho <[email-masked]>
Date: Tue, 11 May 2004 21:51:03 +0900

Hello Marcelo,

 Thanks for some very good comments.

> between them? This implies that MR1 cannot hear RA messages from MR2.

 Right. Actually, I also think about this situation. However, I think this
 problem can be solved from the HMRA (Hierarchical Mobile Router Advertisement)
 which is proposed by H. Cho. And the similar problem happens also in case of
 the nested MR scenario. I'll include this point to the next version.

> egress interface belongs to another link.

 I miss this point in my draft. However, the CoA of the root MR can be 
 included as an option of RA. IMO, this option is simple, but usuful 
 for other solution, like the route optimization.

> understand i one of your goals)

 First, I assume that the MR has a secure association with its HA and the 
 wired node, including HA, can be verifiable using PKIX or other mechanism.
 This assumption is general. And the virtue of RR is the neighbor MR can
 confirm the mapping of a HoA and a CoA using HA's information. From this 
 procedure, we can get the valid mapping of a HoA and a CoA. And this security
 issues have been treated in Mobile IP version 6 Route Optimization 
 Security Design Background <draft-ietf-mip6-ro-sec-00>.

 Second, I think your example attacker can be prevented and our mechanism 
 can provide non-repudiation from the SA between HA and MR.

 Finally, the BCE lifetime would not be the dominant factor for the leaving MR.
 The periodic RA message can be the factor for leaving or unavailable neighbor
 MR. I just use the RR procedure as an authentification mechansim. 

> announced from the MR to the HA.

 I assumed no signalling message between the HA and the new (neighbor) MR.  
 The only required operation is de-capsulation for HA-(old)MR tunneled packets.
 But, the new MR can acquire the MNP from the RA, so this de-capsulation can 
 be done after authentication using RR. 

 Thank you for your comments.

 Regards,
 Seongho

---

From: Seongho Cho <[email-masked]>
Date: Tue, 11 May 2004 21:51:03 +0900

Hello Marcelo,

 Regards,
 Seongho

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 11 May 2004 16:00:50 +0200

>  wired node, including HA, can be verifiable using PKIX or other

Ok, let's define the considered a bit more.
LEt's suppose that the nemo has two MR: MR1 and MR2
There are also two HA: HA1 and HA2.
Additioanlly let's suppose that the MR1 uses HA1 and that MR2 uses HA2.

So i guess you are assuming that HA1 has a SA with MR1 and that HA2 has a SA
with MR2, right?
IMHO this is what can be assumed by default.

Now you are using the RR so that MR1 can verify the collocation of the CoA
and the HoA of MR2 and conversely i.e. the MR2 can verify  the collocation
of  the HoA and the CoA of MR1.

>  confirm the mapping of a HoA and a CoA using HA's information.

What HA's information? i mean this procedure is between the MR1 and MR2, so
what HA are you considering here?

 From this
>  Security Design Background <draft-ietf-mip6-ro-sec-00>.

Yes, but i guess that the RR check is usefull when you want to verify the
collocation of two addresses of a CN that you don't have previous contact
and you are contcting it over the internet, This scenario is quite
different, since the two MRs probably know each other, they are using the
nemo to communicate and you probably want some sort of authorization
information to valiudate that using another MR is safe, Again, i think that
MR1 should be aware of the existance of MR2 through a preconfigured list. I
mean, not all nodes in the nemo are suitable to act as MR.

>  can provide non-repudiation from the SA between HA and MR.

How?
PErhaps you would care to expand on how you can prevent any node with two
addresses to become a MR using RR check?

>  MR. I just use the RR procedure as an authentification mechansim.

YEs but the authentication information is valid only for 7 minutes, after
that, the BCE will disapear and if the other MR is down, you won't be able
to renew it becuase the RR check will fail ( i mean, the router is down, so
it won't be able to reply  RR packets)

>  be done after authentication using RR.

Again, suppose that one of the routers is down.
If you want to preserve the communications that are being carried through
its HA you will need to update the binding information in both HAs as the
nemo moves and changes its CoA, and since one MR is down, the remaining MR
will have to update the binding information on both HAs. With one of the HA
it will have a IPSec SA so no problem, but with the other, it doesn't have
an IPSec SA so it won't be able to update the binding.
This essentially means that if MR2 is down, then the HA2 will send packets
to the MR1, so far so good.
Now the nemo moves, so MR1 changes its CoA, now how do you update the HA1
with the new CoA of MR1?

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 11 May 2004 16:00:50 +0200

From this

How?

Regards, marcelo

---

From: Seongho Cho <[email-masked]>
Date: Wed, 12 May 2004 00:03:44 +0900

> IMHO this is what can be assumed by default.

 Yes.

> of  the HoA and the CoA of MR1.

 Correct.

> what HA are you considering here?

 The RR procedure consists of Home Test and Care-of Test. So, what I want to 
 mention was HA's Binding Cache information of it's MR. I assume that each
 MR and HA pair has correct binding information. From Home Test, MR can 
 verify packets are correctly tunneled to the neighbor MR through its HA. 
 And the CoA which is updated to the HA would be correct through this test.
 
> mean, not all nodes in the nemo are suitable to act as MR.

 IMO, the preconfigured list is not always possible in some cases. Each MR 
 can move dynamically in the mobile networks. Practical situation can be
 the European train. Each train consists of several wagons. And the wagon
 can flock and depart by their destination. Each wagon can join and leave 
 dynamically. Like this example, some situations need dynamic MR authentication  and registration. And this dynamic mechanism would be prefered for convenient 
 network management. My assumption is MR1 could not be aware of the existance
 of MR2 before receiving MR2's RA message.

 And, like you said, not all nodes in the nemo are suitable to act as root MR. 
 MR1 and MR2 should be root MRs which have a connection to the wired network.
 
> addresses to become a MR using RR check?

 My assumption is each MR has its own HA. The single HA case is trivial. 
 My scope is each MR has the different HA. If we refer the HA, we can 
 acquire valid CoA, HoA, and MNP of MR. What I want to verify using RR is 
 the neighbor MR's CoA, HoA, and MNP is correct or not. And if the neighbor
 MR do malicious thing, then we can refer MR's HA. That can be the non-
 repudiation. 

> it won't be able to reply  RR packets)

 Correct. What is the problem in that router failure? Periodic RR test?
 or RR test overhead?

> Now the nemo moves, so MR1 changes its CoA, now how do you update the HA1

 As you said, MR1 doesn't have a IPSec SA with HA2. So, all packets from HA2 
 should be tunnelled though the MR1-HA1 tunnel. And the movement of MR1 is
 another problem. In that case, there exists no alternative MR for failed
 MR2. So, the service cease for MR2-HA2 would be correct.

 Regards,
 Seongho

---

From: Seongho Cho <[email-masked]>
Date: Wed, 12 May 2004 00:03:44 +0900

Yes.

 Correct.

 

 

 Regards,
 Seongho

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 12 May 2004 11:56:57 +0200

>  And the CoA which is updated to the HA would be correct through

I think i am not following this...

I mean, the two MR are on the same nemo, and you assume that each one of
them can listen to the RAdv from each other. This basically means that MR1
can reach the HoA of  MR2 through the nemo, and it will not use the HA. For
accesing the CoA of MR2, normal routing will be used so, i guess you don't
need the HA of MR2 neither. So what binding information are you using?

[...]

>  dynamically. Like this example, some situations need dynamic MR
> authentication  and registration. And this dynamic mechanism
> would be prefered for convenient

I like your example, thanks.
I think that we should distinguish two issues here. I agree that the MR in
wagon 1 will need to discover the other MRs in other wagons, since the
arrangement of wagons can vary. However, i think that that doesn't mean that
they cannot have a list of authorized MR that are acceptable. I mean, alll
the wagons will belong to the train company, so the can have a preconfigured
key.
So you need a mechanism to discover which MR are available from those that
are authorized.
But this is not really the point. The point is about whether the RR check
provides valid security.
In the example of the train, i guess that it is not acceptable that i put my
laptop there, with a WLAN and a GPRS connection and start pretending that i
am a valid MR (who knows why i would want to do that, for instance in order
to try to redirect all the traffic to a key cracking device somewhere else
or divert the traffic to do a mitm attack)
So, how the RR check can prevent me from doing this?
If this is not the attack that the RR can prevent, please describe an attack
that the RR check can prevent

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 12 May 2004 11:56:57 +0200

[...]

Regards, marcelo

---

From: Seongho Cho <[email-masked]>
Date: Thu, 13 May 2004 10:31:05 +0900

> need the HA of MR2 neither. So what binding information are you using?

 Even two MRs are on the same nemo, each MR can have different HA. 
 In the multihoming issues draft, draft-ng-nemo-multihoming-issues-03,
 there is no assumption in case of (N, N, N) cases. And, this situation can
 be possible in my European train example. Each wagon has own MR and each MR
 has its own HA. And some MR can be part of different administrative domain.
 In this case, Each MR can have different HoA (I mean the different prefix). 
 And each MR can be reachable, because most of MRs would have wireless 
 intereface. So, even there exist no bridging router, different MR can 
 access each other with different MNPs. 

> But this is not really the point. The point is about whether the RR check

 I think your assumption is not always possible and it needs lots of 
 assumption and predefined condition. And this case is not the point, 
 as you said.

> that the RR check can prevent

 My point is your laptop also has your own HA. From the RR procedure, your 
 CoA and HoA can be verified. These verified addresses are registered by your
 labtop. And your laptop can be tracable by refering its own HA. So, this 
 process can provide non-repudiation.
 And our process can protect from the MR which advertises the wrong CoA like
 RR can protect wrong BU from MN in MIPv6.
 
 Regards, 
 Seongho

---

From: Seongho Cho <[email-masked]>
Date: Thu, 13 May 2004 10:31:05 +0900

Regards, 
 Seongho