Subject: RE: [nemo] MR definition

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 18 Dec 2002 12:10:20 -0000

Becomes tricky.

The MR is tunneling things home. That may threaten home. So the tunnel home should get the same security level as 'inside' home. 

Seems to me this all boils down to configuration. Whether an authentication such as 802.1x runs on the ingress interfaces with the same policy as home - we run LEAP inside Cisco. Whether visitors are accepted in at all, and whether their packets can be routed over the home tunnel (note that RRH does not require the latter). Whether ingress filtering is performed by the MR on its ingress interfaces, or whether the HA does it when it decaps from a tunnel interface (additional nesting being invisible at that point).

What we must say is which configuration capabilities MAY, SHOULD or MUST be present on HA and MR, correct?

Pascal

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: mercredi 18 décembre 2002 11:52
> To: Vijay Devarapalli
> Cc: Pascal Thubert (pthubert); [email-masked]
> Subject: Re: [nemo] MR definition
> 
> 
> Vijay Devarapalli <[email-masked]> writes:
> > > In the MR case, the src address of the encapsulated packet is not 
> > > MR's CoA, but it is the fixed address of an LFN or the 
> address of a 
> > > visiting MH that derives its CoA from the MNP.  This is 
> probably a 
> > > security threat.
> > 
> > MIPv6 meant check the source address on the outer header. compare
> > it with the CoA in the binding cache entry for the corresponding 
> > home address. this is to prevent a node from tunneling traffic 
> > through the home agent, if it is not registered with the home agent 
> > currently. this is similar to ingress filtering that a router would 
> > do when it forwards packets.
> > 
> > For the MR case, the HA needs to do this check, but the check is
> > slightly different. it has to make sure the source address in the 
> > inner header belongs to the MR's prefix. and the source address in 
> > the outer header needs to match the current CoA of the MR.
> 
> Yes, right.  When nested mobility, and several HAs, then a HA 
> will receive packets from an MR that have several headers 
> inside.  Thus, talking about inner and outer header should be 
> talking about addresses in "outermost"(?) header and "next to 
> outermost"(?) header?
> 
> I mean, the HA will only check src and dst addresses only in 
> the outermost and next to outermost headers, but not the 
> addresses in deeper headers, right?
> 
> Alex
> 
>

---

From: Alexandru Petrescu<[email-masked]>
Date: 18 Dec 2002 14:29:36 +0100

"Pascal Thubert (pthubert)" <[email-masked]> writes:
> Seems to me this all boils down to configuration. Whether an
> authentication such as 802.1x runs on the ingress interfaces with the
> same policy as home - we run LEAP inside Cisco. Whether visitors are
> accepted in at all, and whether their packets can be routed over the
> home tunnel (note that RRH does not require the latter).

This looks to me more like a "make LEAP/Cisco work over the MRHA
tunnel" problem.  Just like "make multicast work over the MRHA
tunnel", or "make renumbering over the MRHA tunnel".

But may I suggest to extract from LEAP/Cisco scenario three things:
(1) the description of how attackers could arrive in a system that is
not protected by LEAP/Cisco, (2) the damage they could cause and (3)
the description of how LEAP/Cisco prevents from this happening.  Maybe
we can find amongst these three descriptions one threat that we could
derive into a NEMO threat.

If we can not derive a NEMO-specific threat, then it is clear that the
suggestion you have is more of "make LEAP work over MRHA tunnel".

An example, please excuse if my description is wrong.  In a system
that runs no LEAP, a non-legitimate user could obtain a valid address,
a default route and access to a DNS server.  Once that user has that,
it could listen to all other connections in that network (traffic
analysis), it could download large files for extended periods of time
(DoS for networking resources to legitimate users) or it could attack
other systems (masquerading).  However, in a system where LEAP is
active, a user is required to authenticate to LEAP by showing evidence
of owning a secret password.  In this way, users that are not
legitimate and have no passwords will not be offered neither a valid
address, nor a default route, they will not be allowed to talk at L2
layer, they will not be able to DoS, or masquerade or analyze the
neighbours' traffic.

Now, in the above description substitute "network at home or away from
home" for "system" and the whole problem becomes a problem of "making
LEAP work over MRHA".

Alternatively, one could describe the following: a non-legitimate user
visits a mobile network that is not at home.  That mobile network is
nested under 3 other mobile networks that are themselves nested one
under the other.  The attacker, instead of using the CoA as source
address, it uses a fake source address (the address of a legitimate
user).  In this scheme, if the HA does ingress filtering, the attacker
will be able to provoke DoS of network resources on the path between
TLMR's HA and the immediately above MR's HA.  In this scheme, MR
ingress filtering could help, and HA ingress filtering could help by
looking at deeper headers.

What do you think Pascal?

> Whether ingress filtering is performed by the MR on its ingress
> interfaces, or whether the HA does it when it decaps from a tunnel
> interface (additional nesting being invisible at that point).

Yes, good question.  It would be fine to require both MR and HA to do
ingress filtering.  MR ingress filtering is simpler to specify than HA
ingress filtering.

Alex