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

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

> 
> > 1) I expect AR to check the source address (per standard)
> So do I.
> > 2) I expect AR to actually be the TLMR and the source of the packets
> as
> > seen by HA
> 
> 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.

> > 3) I expect that the infrastructure is safe (if it is not, again,
> there
> > are other
> >     simpler attacks for a rogue on axis
> >
> 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.
> 
> > 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: "Jongkeun Na" <[email-masked]>
Date: Sun, 21 Sep 2003 23:16:51 +0900

Hi Pascal,

> For instance attacker is TLMR, forges source or RRH, and then what

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.

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

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. 

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.

Best Regards,
/Jongkeun

---

From: "Jongkeun Na" <[email-masked]>
Date: Sun, 21 Sep 2003 23:16:51 +0900

Hi Pascal,

Best Regards,
/Jongkeun