Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Sep 2003 07:26:04 +0100

Hi Jongkeun (and all)

First, thanks for this piece of work and for the in-depth study you are
making. Also it seems to me it's OK discuss the RRH in the ML since the
basic draft is pretty advanced now...

I have few issues about the first version of draft:

1) I'm not sure what the security issue is exactly; after Chan-Wah and
Takeshi published their draft, we spent quite some time discussing the
possible attacks against RRH. I talked again about that with Hiroyuki
Ohnishi from NTT on the same subject. We have not identified an attack
against RRH that could not be done more easily otherwise. Could you
please consider the threat analysis in more depth so we understand which
issue you address exactly?

2) TIO has a hash of the nested CareOf. This is used to discover a
branch level mobility somewhere between the MR and the AR. It seems to
me that this information alone would be enough if we wanted to
proactively sign the RRH. But then this delays the movement tracking,
since we need to wait for the MR to learn about the movement. This is
why we did not do it. Again, we need a threat analysis that would
uncover a threat against the current draft.

3) Note that the RH type 2 in RRH can only go down the tree, why
protects against a rogue within the tree from bombing outside the tree.
The rogue will get the traffic back anyway. IPSec is recommended to
protect the packets. Seems that the worst that can happen is blacking
(or graying) out. Which could be done easily at the radio level or by
discarding the packets. 

4) For an attacker in the infrastructure (between AR and HA), the threat
may be different since it could bomb any place at will. But a router
placed like this could do a lot more than changing RRH. It could forge
topology correct packets (source and dest) and generate the attck
itself. We expect that these (core) routers are secure.

5) If a path is not working, the MR should try another one. Our view is
that MR should overtime build several CareOf via several ARs, and select
the best path based on metrics such as bandwidth. What's the difference
between a bad guy blacking you out and a good one with no upstream
bandwidth?

What do you think?

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: mardi 16 septembre 2003 20:53
> Cc: [email-masked]
> Subject: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
> 	Title		: Secure Nested Tunnels Optimization using
Nested Path
>                           Information
> 	Author(s)	: J. Na et al.
> 	Filename	: draft-na-nemo-nested-path-info-00.txt
> 	Pages		: 21
> 	Date		: 2003-9-16
> 
> This document addresses how to securely achieve the nested tunnels
> optimization using nested path information that reflects the
> optimized path from Top Level Mobile Router(TLMR) to Mobile
> Router(MR) in nested mobile networks.  The solution is based on
> Reverse Routing Header(RRH) idea and the concern of security problem
in RRH. By carefully
> taking a look at the simplicity of
> Routing Header Type 2 routing mechanism and the complexity of
> Access Router Option(ARO) based solution to get rid of the threat
> of possible attack for RRH, the proposed solution has been
> considered to preserve the efficiency of RRH without the lack of
> security.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-na-nemo-nested-path-info-00.tx
t
> 
> 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-na-nemo-nested-path-info-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-na-nemo-nested-path-info-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: "Jongkeun Na" <[email-masked]>
Date: Fri, 19 Sep 2003 00:10:15 +0900

Hi Pascal,
Thanks for your interest.
I also think it's a good time to discuss RO issue.

> issue you address exactly?
Basically I mean the spoofing attack for RRH in which some intermediate
MR(faked or one victim of attacker) can easily insert arbitrary address
in arbitrary slot. In other words, that can cause the redirection of the
forward routing path under no detection in both HA and MR during some
period time. The packet redirection by the spoofing attack means that
the attacker can give us the following threats.

1) Information Disclosed - if the packets forwarded by HA are redirected
to the node(which is a repository for capturing some information for the
attacker) on Internet, that information will be used to do the second or
third attack. I think that it will be still helpful to the owner even if
it is encrypted because it can be an input to the traffic analysis or to
decrypt the cipertext.
2) Active Denial of Service - if all packets sent from HA(/CNs) can be
redirected to some targeted server(as a victim) on Internet, it becomes
one of holes for DOS attack.

Above two cases are just all of my instant thinking but I expect another
cases apparently exist in the real world. We should try to find more
threats. Are above mentioned threats reasonable or not? It needs more
discussion.

> uncover a threat against the current draft.
Good insight. If I knew in advance your intention about this, it would
help me.
At first while I was reading your draft, I wondered why TIO is only
limited used.:)
About movement tracking delay, I agree it need more delay than RRH based
per-packet. But, I think some delay is tolerable for the security
because nested relationship is unlikely changed too frequently. 

> (or graying) out. Which could be done easily at the radio level or by
If TLMR is a faked one, it's possible. Is'nt? And an intermediate
MR(which is controlled by the local attacker) can make the packets to
redirect to some information processing node in the same local link.

> itself. We expect that these (core) routers are secure.
In our draft, one MR can be AR to MR which is in one level down. In
here, AR means one of nested MRs, not true fixed access router in the
infrastructure. We should suspect the nested MR is correct for above
threats I mentioned. In contrary, RRH is fully depend on the trust
relationship among nested MRs. How to get that MR-MR relationship of
trustworthy if MRs do not have the same administrative domain? This
maybe out of scope of our disccusion. For this, at least we need to
protect the integrity of the routing path between TLMR and MR to which
MR designates.

> between a bad guy blacking you out and a good one with no upstream

The selection problem of best path is another point we should consider.
I think MR can choice the best path by its own policy or simply
information which can be provided by the upper-level MRs/ARs.
Particularly it is more valuable feature under the multi-homed nested
environment.

/Jongkeun

---

From: "Jongkeun Na" <[email-masked]>
Date: Fri, 19 Sep 2003 00:10:15 +0900

Hi Pascal,

/Jongkeun