Subject: [nemo] [Fwd: I-D ACTION:draft-ng-nemo-rrnp-00.txt]

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 20 Oct 2004 10:34:29 +0800

Hello Alex & all, 

As I have mentioned earlier in the thread on RO Taxonomy Draft, I was
thinking about the issue of return routability procedure when applied in
NEMO.  Well, the thought process manifest itself into a draft for your
reading pleasure, information of which you can find in the forwarded
announcement below.

One thing I like to highlight is that this draft is NOT a route
optimization solution.  I view it as identifying a potential security
problem of NEMO-RO, and then proposing a mechanism to address this
problem.  This mechanism may be incorporated in future NEMO Extended
Support should there be a need.

As always, comments, criticism, suggestions welcomed (regardless of
harsh or not :)).

Thanks.

/rgds
/cwng

-----Forwarded Message-----
From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-ng-nemo-rrnp-00.txt
Date: Tue, 19 Oct 2004 07:47:00 -0400

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

	Title		: Extending Return Routability Procedure for Network 
			  Prefix (RRNP)
	Author(s)	: C. Ng, J. Hirano
	Filename	: draft-ng-nemo-rrnp-00.txt
	Pages		: 24
	Date		: 2004-10-18
	
This memo highlights the inadequacy of existing return routability
   procedure when one takes network prefix into consideration under the
   context of route optimization with Network Mobility (NEMO).  An
   extended return routability procedure, called Return Routability with
   Network Prefix (RRNP), is thus proposed to address this problem.
   With RRNP, a correspondent node can verify the collocation of care-of
   address, home address, and network prefix(es) specified in a binding
   update message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ng-nemo-rrnp-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-ng-nemo-rrnp-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-ng-nemo-rrnp-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.

________________________________________________________________________
Content-Type: text/plain
Content-ID: <[email-masked]>

________________________________________________________________________
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce
ENCODING mime
FILE /internet-drafts/draft-ng-nemo-rrnp-00.txt

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Oct 2004 12:38:15 +0200

Hi Chan-Wah,

Thanks for the draft.

I think that the idea of randomly selecting one address to perform the  
RR check in order to prove prefix "ownership" is very nice.

However, before entering into details, i have a more general concern:  
Why do you think that a prefix BU with the CN is needed?

I mean, i understand that it makes sense to have a BU that affects a  
prefix with the HA, since all the packets addressed to the addresses in  
the prefix will be routed through the HA.
However, in the case of the CN, the CN wwill be probably communicating  
with a few nodes within the nemo (probably in most cases with only one)
In this case, the benefit of having a bu that affects a prefix seems  
really reduced, since it only provides benefits in those cases when  
more than one MNN of the nemo is communicating with the same CN. Do you  
think this is worth the effort? (i mean changing the BU implies  
modifying all CNs)

Regards, marcelo

> implementation to automatically retrieve the ASCII version of the
------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 21 Oct 2004 19:07:02 +0800

Hello Marcelo,

> RR check in order to prove prefix "ownership" is very nice.

Thank you.

> Why do you think that a prefix BU with the CN is needed?

I am just anticipating it.  More below.

> think this is worth the effort? (i mean changing the BU implies  

I understand your line of thinking.   But firstly, I am assuming a RO
solution requires MR to send prefix to someone (except its own HA) in
the BU, not necessarily CN.  For instance, a correspondent router. Then
the RRNP can be used by that "somebody" to check the validity.

Secondly your argument is more on arguing against a RO solution that
requires new functionality be implemented on CN.  I am not promoting
one.  I am just anticipating that should such a RO solution materialize,
my RRNP proposal may be useful.

Thirdly, the RRNP is an extension, not a change in the original RR
procedure.  We don't require all CN to understand the new RR procedure.

Fourthly, addressing your comment on BU with a prefix to CN where there
is only one MNN communicating with the CN.  But what is the
alternative?  By sending only normal BU, it is not enough to establish
optimized route.   

Of-course, I understand that there is other approaches to route
optimization that will keep CN untouched.  If the final solution
selected by the WG (after re-charter) does not require the verification
of a network prefix, then fine, I treat my RRNP as a useful classroom
exercise.  Otherwise, I suspect that my RRNP may prove useful.

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 24 Oct 2004 16:26:14 +0200

> solution requires MR to send prefix to someone (except its own HA) in

i would challenge that, see below (in  the alternatives part)

> the RRNP can be used by that "somebody" to check the validity.

agree

> my RRNP proposal may be useful.

ok

> procedure.  We don't require all CN to understand the new RR procedure.

well, all RO approaches are an optimizaion aren't they? we can always  
fall back to basic support, so i don't buy this one.

> alternative?  By sending only normal BU, it is not enough to establish

Why not?

in the most cases (AFAICS) a given CN will only be communicating with a  
single MNN of a given nemo. so in this case, you only need to tell that  
CN which is the CoA of the MNN (i.e. present the CoA of the MR as the  
CoA of the MNN using MIP)
for that the BU of MIP is enough.

So i would say that you could simply use mip BU unchanged.

I see the prefix scoped BU as an optimization of the mip BU which only  
benefit is to reduce the number of messages when the CN is  
communicating with more than one MNN of the same nemo simoultaneously.  
My question is if such optimzation worth the deployment effort.

> exercise.

As i already mention, i think that the RRNP is a nice approach to use  
RR to verify a prefix BU. However, i am not sure that the CN should do  
this.

Summarizing:

imho the RRNP is an interesting tool to verify a prefix
imho implementing this at the CN level is not worth the effort (i.e.  
the obtained benefits doesn't seems so much imho)

Regards, marcelo

>  Otherwise, I suspect that my RRNP may prove useful.
>
> /rgds
> /cwng
>
>> Regards, marcelo
>>
>>> [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
>>> _____________________________________________________________________ 
>>> __
>>> _
>>> Content-Type: text/plain
>>> _____________________________________________________________________ 
>>> __
>>> _

---

From: Chan-Wah NG <[email-masked]>
Date: Sun, 24 Oct 2004 23:37:26 +0800

Hello Marcelo,

> i would challenge that, see below (in  the alternatives part)

again, I am not saying an RO solution must.  I am just anticipating one,
if if things really go this way, I foresee a problem.  Hence a solution
for a problem I foresee.

> fall back to basic support, so i don't buy this one.

you are absolutely correct, so the same logic that applies to MIPv6 RO
applies here.  If CN don't implement RRNP, they don't enjoy optimized
route.  Things don't break because CN don't want to implement something
new, which is my point.

> for that the BU of MIP is enough.

Yes, but whose HoA should the MR use?  If MR uses its own HoA, its not
going to achieve anything.  MR needs to tell CN more information (i.e
HoA of MNN), and CN will need to verify this new info.  In an extreme
way of looking at it, the HoA of MNN can be treated as a prefix with
length 128.

Alternatively, we can go the Proxy approach, where MR send the BU on
behalf of MNN (it pretends to be the MNN).  Personally, something
doesn't feel right to me with this approach (reminds me of NAT), but I
concede that this will keep the CN unchanged.

> the obtained benefits doesn't seems so much imho)

Thank you!  Then I presume that you are all for a RO solution that will
keep CN untouch.  That's fine, I would want one with that feature too. 
However, if a RO solution impact CN, then I see no reason why CN should
implement RRNP alongside with the "new RO functioanlity".

/rgds
/cwng

---

From: Chan-Wah NG <[email-masked]>
Date: Sun, 24 Oct 2004 23:54:33 +0800

> implement RRNP alongside with the "new RO functioanlity".

Sorry, the "should" in the last sentence should read "shouldn't"
instead.

/rgds
/cwng

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 24 Oct 2004 22:17:35 -0700

Chan-Wah NG wrote:

I had a quick look at the draft.
Trying a random address in the prefix is neat, but might be insufficient.
For instance, if a MR is assigned a /64 prefix, then with probability 
1/2 it can use the /63 prefix (and steal its "neighbors" packets).
So it is only a question of how many times it needs to try before it is
succesful.

If we believe "try a random" is in general good enough, then we can 
modify the random calculation to be less random:
If the prefix is N bits, then form the test address by inverting the 
N+1'th bit and making the remainder of the test address be random.
Thus in the above /63 example, the test address would always come from
the "neighbors" /64 prefix and the attacker would never succeed.

This still makes it possible for two friends with different prefixes to 
claim a the whole range of addresses between them;
If A has prefix 1:2:3:0xyz:/64 and B has prefix 1:2:3:8abc:64 then with
some non-zero probability, when B sends a HoTI for the /48 prefix with a 
non-zero probability the NPT would be sent to A, who can forward it to B.

We can reduce that probability by sending more than one NPT for 
different addresses in the prefix.

But until we understand the utility of CNs receiving BUs for prefixes,
this is rather academic.

   Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 25 Oct 2004 11:23:10 +0200

> different addresses in the prefix.

Or we can reserve an address out of a prefix as _the_ address that 
corresponds to testing that entire prefix.

> But until we understand the utility of CNs receiving BUs for prefixes,

One utility would be to get rid of encapsulation MR-CN.  This 
encapsulation happens supposedly because MR can not modify the source 
address of packets from LFN to CN after the enhanced-RR procedure (the 
one adding the DO and RH).  Or am I wrong to think this encapsulation is 
absolutely necessary?

Alex

---

From: Chan-Wah Ng <[email-masked]>
Date: Mon, 25 Oct 2004 20:19:01 +0800

> corresponds to testing that entire prefix.

One address might not be enough, if we allow variable length prefix. 
But that is a good point.  Question is if the verification of some
specific addresses can ensure the whole prefix.  One must consider the
scenario Erik points out where the attacker and some friends collaborate
to snoop part of a /48 prefix, where they only own some of the /64
prefixes out of the /48 prefix.

> One utility would be to get rid of encapsulation MR-CN.

Now, that is one utility I have not thought of.  Care to share with us
what you have in mind?

/rgds
/cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 25 Oct 2004 16:04:10 +0200

Chan-Wah Ng wrote:
> specific addresses can ensure the whole prefix.  One must consider 
> the scenario Erik points out where the attacker and some friends 
> collaborate to snoop part of a /48 prefix, where they only own some 
> of the /64 prefixes out of the /48 prefix.

I'm just vehiculating the idea that out of any prefix a "dedicated"
"IANA-reserved" address can be used for RR verification.  It is only an
idea and Erik's point is right.

>>> But until we understand the utility of CNs receiving BUs for 
>>> prefixes, this is rather academic.
>> 
> Now, that is one utility I have not thought of.  Care to share with 
> us what you have in mind?

Sorry, I did not mean to be laconic and I've probably not identified the
exact utility as perceived in your context.

I meant that if CN has a pair in a cache with a prefix matching the
address of LFN (LFN has only one address) and the CoA of MR then CN
would not need to encapsulate (adding a new base header) when writing to
LFN, just use the RH.

Mobile IPv6 uses RH from CN to MN (MH!) so it would be also better to
use it from CN to MR, instead of new-base-header encapsulation.

Also meant that it would be more efficient to have a unique entry in
this cache, of the form prefix-MRCoA, that would be used for all LFN's
instead of several entries, one per LFN.

I hope I'm not far away from the discussion, sorry if that's the case.

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 25 Oct 2004 16:21:06 +0200

Hi Alex,

<snip>
> use it from CN to MR, instead of new-base-header encapsulation.

	I think that the same RH can be used in this case too, so you don't
need to introduce changes in the CN operation.

> instead of several entries, one per LFN.

	In order to do that you'd need to change the CN operation. Do you think
it's worth to do that? IMHO, maybe there are not many cases in which a
CN is talking to many LFNs belonging to the same NEMO. What do you
think?

	Kind Regards,

	Carlos

-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Oct 2004 09:29:49 -0700

> corresponds to testing that entire prefix.

For every of the 127 possible prefix lengths and for all parts of the 
IPv6 address space?
So if I want to do a BU for 0::/3, you need to reserve how much of the 
address space? Seems like a lot.

> one adding the DO and RH).  Or am I wrong to think this encapsulation is 

I don't understand. The source address needs to be correct with respect 
to the place where the packets are injected in the network to prevent it 
being filtered *and* the source address needs to match the ULP (e.g. 
TCP) connection state at the receiver.
Thus the only way to avoid carrying two IPv6 addresses for the sender is 
that the receiver is aware of which address the ULP needs (based on some 
state setup between the two endpoints) - this was first suggested for 
MIPv6 in the ZOD draft.
And multi6 is looking at exactly that approach.

But I don't see what this has to do with a BU per prefix since the state 
setup must be for each pair of hosts in order to be robust against 
packet loss and node failures/state loss.

    Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 25 Oct 2004 19:49:33 +0200

Erik Nordmark wrote:
>> encapsulation happens supposedly because MR can not modify the
>> source address of packets from LFN to CN after the enhanced-RR
>> procedure (the one adding the DO and RH).  Or am I wrong to think
>> this encapsulation is absolutely necessary?
> 
> I don't understand. The source address needs to be correct with
> respect to the place where the packets are injected in the network to
> prevent it being filtered

Ah yes, that again, correct, sorry.

Alex

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 26 Oct 2004 00:04:45 +0200

> Yes, but whose HoA should the MR use?

I was thinking in the MIRON approach (sent to the list by Carlos Jesus)

In this case, the MIP CN capability is used, using the MNN address as 
the HoA and the CoA of the MR as the CoA of the BU

> If MR uses its own HoA, its not

> implement RRNP alongside with the "new RO functioanlity".

  agree (with the shouldn't of course)

regards, marcelo