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

From: [email-masked]
Date: Tue, 16 Sep 2003 14:53:27 -0400

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.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-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: "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
> 
> Reverse Routing Header(RRH) idea and the concern of security problem
in RRH. By carefully
> taking a look at the simplicity of
http://www.ietf.org/internet-drafts/draft-na-nemo-nested-path-info-00.tx
t

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Sep 2003 17:39:22 +0100

> 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.
> 

Well, there's the RH type 2 forwarding rules that make the attacker get
The packets back to him, if the attacker is in the nested structure,
as we explain in the draft. I expect that in general the TLMR will be 
actually the AR, in order to prevent faking the Source of the packet as
seen
by the HA.

I believe that the result is the same exactly if the TIO extension you
propose
is faked. And I agree with your conclusion that the attacks that this
opens to
could be done in an easier fashion by other means.  Same exactly for RRH
:)

> 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.

Again, RH2 will not let the packet leave the nested structure once it is
in.
If you want, the nested structure is seen globally as a black bow. Once
the
packet is in, it will never get out. Always down the tree.

> 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.

If the access router is not TLMR and if it does not check tke
topological
Coreectedness of the source, it may happen that an attacker forges the 
Source of the packet. But then you do not need all the MIP thing to do
that.

1) I expect AR to check the source address (per standard)
2) I expect AR to actually be the TLMR and the source of the packets as
seen by HA
3) I expect that the infrastructure is safe (if it is not, again, there
are other
    simpler attacks for a rogue on axis

So the threat you mention is covered.... for both drafts. Again, I do
not see what the
RH6 adds there since the info you have may be faked for all you know...

What do you think?

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Sep 2003 17:51:41 +0100

> 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.:)

There's MUCHO more to it. Eg AR selection, loop avoidance :)

> 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.
> 

If you prove me that you bring any additional security where there
was a threat, right? 

> 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.
> 

Same with your draft, or did I miss something? But then again, it's easy
to
prevent this by having plain ingress filtering rules at the AR and
optionally
by placing a TLMR there.

> 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.
> 

You do not know that path for sure so how would you protect it? 

The info you get in TIO may be all faked as well. I do not understand
your point of RRH being dependent on the MR-MR trust. Can you please
detail? In my mind there's no such a thing.

> 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.
> 

Fully agreed.

And TIO is a powerful tool for that selection, as you realized for sure.

Add a few dynamic metrics to evaluate, say, the bandwidth of alternate
path,
and there you go.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Sep 2003 17:51:41 +0100

based

consider.

Fully agreed.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Sep 2003 10:02:03 +0100

Hi:

I'd like to focus on the attacks you have in mind and make a scenario. 
For instance attacker is TLMR, forges source or RRH, and then what
happens.

> 
> The result is not the same. In our extended scheme, the nested path
> information(eg. MR1_COA->MR2-_COA..) which carried in RH6 is not
> mutable, so that information can be protected by AH using SA
established
> between HA and MR. If the path information is forged, it will be
> promptly detected by HA. The HA will discard the forged path
information
> by checking AH integrity and will never send the packets using RH2
which
> contains that forged path. In case of the original RRH, the slot
> information is mutable that means AH cannot be applied. So HA cannot
> detect whether that slot information is valid or not.

I understand that the RH6 as you describe is non mutable. 

Note that in my mind, it should not work exactly as you describe but
rather the reverse way of RH0 and RH2, with a swapping of the source.
                     
          <--------------- outer IPv6 header ---------------> 
          +-------+-------++ -- ++----+---+--------+---------++-------- 
          |oSRC   |oDST   |:    :|oRH |IDX|Addr[1] | Addr[2] ||

     MR2: |MR2_CoA| HA3   |:oEXT:|type| 1 |MR1-CoA | MR3-CoA || iPACKET 
          |       |       |:    :| 6  |   |        |         || 
          +-------+-------++ -- ++----+---+--------+---------++-------- 
                     
          <--------------- outer IPv6 header ---------------> 
          +-------+-------++ -- ++----+---+--------+---------++-------- 
          |oSRC   |oDST   |:    :|oRH |IDX|Addr[1] | Addr[2] ||

     MR1: |MR1_CoA| HA3   |:oEXT:|type| 0 |MR2-CoA | MR3-CoA || iPACKET 
          |       |       |:    :| 6  |   |        |         || 
          +-------+-------++ -- ++----+---+--------+---------++--------

Now it's mutable but predictable. I believe it's cleaner and that may 
Make the HA MIP extension simpler.

Now, my point is that the Nested Path Information may be forged all the
same.
So you sign something that you believe but can not verify? Or can you? 

I'm still missing the threat against RRH. If we find one, we'll see
whether
It does or does not translate equivalently in a threat against NPI.

My current understanding is the added security is but an illusion, at a
cost...

> I understand RH2's routing property you are now mentioning. However,
to
> my knowledge, there will be still a threat that redirects the RH2
routed
> traffic to the outside of tree if TLMR can forge the slot information
in
> RRH.

Well, the TLMR will get the response traffic back to it. So what's the
point?

> >
> > > 2) Active Denial of Service - if all packets sent from HA(/CNs)
can
> be
> Actually the attacker in the nested RO context does not forge the
source
> address of the packet. The attack point is in the RRH information that
> will be used to do RH2 by HA.

As above. The HA sends the packet to whom he sees as the source of the
packet, with a RH2 that's the reversed RH (4 or 6). So the response
packet is directed to the TLMR CoA, which topological correctness was
checked by the AR. It's bombing itself... or at least someone on its
link. A bit of a complex method for a simple result.

> So do I.
> Why do you think TLMR will be AR(in the infrastructure)? I think TLMR
is
> just one of MRs that aware/understand the network mobility.
> 

It's a deployment issue. There's added value for doing it. Security is
one. Value added services such as HMIP, HA, DHCP-PD can be indicated in
TIO. Not the core of the discussion anyway.

> I agree. Let's assume the infrastructure is safe in this discussion.
> The threats I said are not depend on the assumption that the
> infrastructure is unsafe.
> 

Agreed. 

> /Jongkeun.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 22 Sep 2003 08:20:48 +0100

> From: Jongkeun Na [mailto:[email-masked]]
> Sent: dimanche 21 septembre 2003 16:17
> To: Pascal Thubert (pthubert); [email-masked];
[email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt
> 
> Hi Pascal,
> 
> Understood. It will not happen to send RH2 packet out to the outside
of
> tree if the followings are guaranteed.
> - The AR's ingress filtering
> - The RH2 and IPv6 Hierarchical Address semantics
> In that case, I also do not see any difference in RRH whether it is
RH4
> or RH6.
> Right, I'm sure that we agreed with this point. IMHO, you need to
revise
> your draft that saying " It is still an issue how to validate that the
> source of the outer
>    packet is the actual TLMR as opposed to a forged IP address put by
an
>    on-axis attacker outside the Mobile Network." In section 11.2.
> because that statement had suggested to me to have the elements of
> threat like as we discussed.

Oups: yes I need to make that clearer. Also to make clear that such an
on axis
Attacker may have better ways to kill the traffic.  
> 
> However, I have still a doubt in the possibility of packet redirection
> through RRH attacking in the tree. For instance,
> 1) A faked MR on the path of Tree makes the RH2 to be redirected to a
> node as a sink one by forging the RRH's slot information.

Why not just drop the egress packets? Or scramble the radio? The results
is 
that the binding flow does not complete and the tunnel is not
established.

> 2) HA should not detect so sends the packets with RH2 as the intention
> of an attacker.
> In that situation, if HA can detect the unauthorized changes in RRH
> using AH integrity protection like our approach, HA will never
respond.
> Well, those kinds of threat do not severely effect on an important
> network node but can bring some adverse result on the tree network
> itself such as the exhaustion of network bandwidth.

I wonder what happens if the same attacker tricks the NPI. For instance,

pokes an address that is not his careof? Isn't this leading to the same
thing?

Note that each MR on the path should do ingress filtering, for both
solutions.
In my mind the 2 are not so different, fundamentally. Say that NPI
precomputes 
the Path and that RRH discovers it on the way. 

The main difference is the latency of discovery but I'm pretty confident
that 
both are safe enough for the purpose.

There's no perfection in network security is there?

> 
> What do you think for those kinds of attack? By virus code, MR may be
> one in WPAN.
> Regardless of its importance, I'm just saying the possibility that can
> cause the adverse effect by having no RRH integrity protection. This
may
> still an illusion to you. But, I think that the security consideration
> on any protocols/mechanism is very critical, so some level of
> over-thinking is necessary.
> 

Right, this is why I'm very opened to this form of discussion. RRH gives
a
false impression of unsafety, and this lead people in the past to
complex 
solutions to fix an unclear threat. On the other hand, NPI seems safer
but 
if it is truly an illusion, then it's a bit deceptive and dangerous,
isn't it?

> Through the discussion, I've realized some flaws in our draft. Your
> comments were very valuable so I'd like to sincerely thank you at this
> time. And also I believe that RRH idea is getting more resistible for
> the potential security threats through our discussion.

Thank you too. Your comments on RRH draft are very welcome also :) 

> Best Regards,
> /Jongkeun
> > My current understanding is the added security is but an illusion,
at
> a
> > > > > cases apparently exist in the real world. We should try to
find
> > more
> > > > > threats. Are above mentioned threats reasonable or not? It
needs
> > > more
> > > > Coreectedness of the source, it may happen that an attacker
forges
> > the
> > > > Source of the packet. But then you do not need all the MIP thing
> to
> > do
> > > > that.
> > > >
> > >
> > > > 2) I expect AR to actually be the TLMR and the source of the
> packets
> > > as
> > > > seen by HA
> > >
> > > > 3) I expect that the infrastructure is safe (if it is not,
again,
> > > there
> > > > So the threat you mention is covered.... for both drafts. Again,
I
> > do

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 22 Sep 2003 08:20:48 +0100

[email-masked];
of
RH4
revise
an

respond.

may

at
find
needs
forges
again,
I