Subject: RE: [nemo] MR definition

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 18 Dec 2002 14:05:50 -0000

> 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",

LEAP (and 802.1x for that matter) is a L2 thing. It gives a secured L2 access to an ingress network.
It does not "work over the MRHA tunnel" -though connection to the back end will happen there- but filters out who can join in the ingress network at L2. This is the first barrier to protect the MR and the home.

Giving away a broadcast access on a ingress network to an anonymous visitor opens to ND attacks, which can easily disrupt all traffic on that ingress interface. We may want to look at what SeND does but at the moment, it's suicidal, so an existing L2 access control seems desirable.

Letting anonymous Visitors on the MRHA opens the home door to strangers. I suggest we install a lock.

I mentioned LEAP because if you consider Cisco premises as my "home", I can log in from outside of the building using 802.11/LEAP. Since LEAP provides a security level that matches the policy 'inside', I can use it from 'outside'. If a MR has a secured MRHA tunnel to the inside of Cisco (a VPN) then LEAP is required on the ingress interface to maintain the security policy.

Pascal

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: mercredi 18 décembre 2002 14:30
> To: Pascal Thubert (pthubert)
> Cc: Vijay Devarapalli; [email-masked]
> Subject: Re: [nemo] MR definition
> 
> 
> "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
> 
>

---

From: Alexandru Petrescu<[email-masked]>
Date: 18 Dec 2002 15:31:34 +0100

> strangers. I suggest we install a lock.

Yes, perfect, there are two possible locks: SEND and Diameter.  Which
does one prefer?

I guess LEAP is out of discussion.  I mean we can jump and leap here
and there out of the context, just for the fun of it, but I don't
think we could seriously look into security analysis based on the LEAP
tool.

My oppinion only, group members may think otherwise.

Alex

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 18 Dec 2002 12:04:15 -0800

> My oppinion only, group members may think otherwise.

I think we should look at different legs of security here
regarding network access:

- Between a host and the mobile network: This is a network
access authentication issue. One can use PANA/802.1x/PPP between
the node and the access router.

- Between the MR and the access router on the Internet side:
This is also a network access authentication issue. Again,
one can use PANA/802.1x/PPP between the MR and the access router
on the Internet side.

- Between the MR and HA: The binding updates sent by MR should
provide sufficient authentication information for creating the
tunnel between two. Further protection can be provided by
per-packet authentication (and encryption if desired) of
the tunnel (e.g., using IPsec AH tunnel mode).

Just to put things in perspective:

LEAP is an instance of 802.1x standard. In this discussion, 
we can refer to 802.1x instead of this vendor-specific implementation.

SEND is not concerned with network access authentication. That is
the job of PANA. SEND addresses other posible threats once a client is
admitted (after authentication and authorization) to the network.

DIAMETER is a specific AAA protocol. In the context of access
authentication, it can be seen as the backend transport for
authentication messaging between the local AAA server and remote
AAA server. For example: PANA carries the authentication
information between the host and the access router in the NEMO. 
DIAMETER can carry the authentication information between the access
router and the AAA backend (possibly sitting somewhere on the Internet).

alper

---

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

Alper, thank you for putting things in a clear perspective.  May I try
to fit my previous oppinion in this framework.

> the node and the access router.

Yes, and I understand that PANA/802.1x/PPP without a backend tool such
as DIAMETER is probably not very useful?  Or maybe I'm wrong?  Please
clarify whether this can be done.  If not, then 802.1x with a DIAMETER
backend should work well when MR's CoA has changed.  So I could state
this into a problem of making DIAMETER work over MRHA, that was my
previous intention.  Or maybe there's nothing to modify on any
backend, it will work just fine over the MRHA tunnels.

> one can use PANA/802.1x/PPP between the MR and the access router

Yes, in that case, the DIAMETER backend will not be affected by any
form of mobility, because AR is fixed and is connected to a fixed
backbone.

> the tunnel (e.g., using IPsec AH tunnel mode).

Yes, exactly, that's the kind of issues that are very important here I
believe.  And I would be very interested to see what are the risks
that are eliminated with this strong security between MR and HA.

Thanks,

Alex

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 18 Dec 2002 13:39:54 -0800

Hi Alex,

> clarify whether this can be done.

Nothing in those protocols require a AAA backend. They can utilize
local database stored on PAA/AP/NAS. But in reality, they are/will_be
used with the AAA backend for centralizing AAA information and supporting
roaming.

> If not, then 802.1x with a DIAMETER

As far as admission control is concerned, I don't think we have to change
anything in DIAMETER for host-AR authentication, or for MR-AR
authentication. Accounting is a different story.. NEMO might move from
cheaper access network to a more expensive access network. NEMO
does not have to authenticate the hosts again, but does it want to
increase the rates that are applied to the hosts? Does it want to inform
them?

alper

---

From: Chan-Wah Ng <[email-masked]>
Date: 19 Dec 2002 10:28:16 +0800

> used with the AAA backend for centralizing AAA information and supporting

Just to re-emphazoe what Alper had said:
True that nothing in PANA/802.1x/PPP requires a backend protocol.  But
without a backend protocol, you are requiring each mobile router to
carry the AAA database ... a administration nightmare, IMHO.

The more pratical deployment scenario I see is that MR will use backend
AAA protocols to check credentials of hosts with AAA databases located
at the home domain (possibly at the other side of the Internet, hence a
need for Internet-wide protocols such as Diameter/Radius).

> increase the rates that are applied to the hosts? Does it want to inform

Is it the current practice of service providers to change rates without
notice during a on-going sessions? 

Possible deployment scenarios I see is:
(1) Service provider (of the mobile network) charge a flat fee no matter
where the mobile network roams to.  Hence no need to inform the visiting
hosts.
(2) Service providers state on the subscription policy that the rates
will be based on the current access network the mobile network roams to,
and vary the rates accordingly, without notifying the hosts.
(3) As above, but hosts are notified when a rate change occurs.  But the
question is, is there mechanism in PANA/802.1x/PPP to support such
notifications?

/cwng

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 19 Dec 2002 09:36:17 -0600

>question is, is there mechanism in PANA/802.1x/PPP to support such
PANA is not a protocol for accounting, only the last A of AAA is for 
accounting.

>--behcet