Subject: [nemo] Some Threats (related to AAA and NEMO)

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Feb 2003 08:53:32 -0000

This discussion comes very close to route optimization, and I'd wish to make sure we all agree that for the moment, we've been doing it in the scope of basic Nemo support, and we limit our investigation to that scope for the time being. 

In that context, , we all seem to agree with Alper's view. The Mobile Router (2) attaches to an Access Router (1). If the AR (1) is also an other MR - making  to (1) a Mobile Access Router - so be it, but it has to be transparent to (2). In the same fashion, (2) is a AR for its VMNs, but they must not need to know it is a MR as well. 

There's a correlated work to be done on threat analysis. You can't just let someone autoconf an address and then AAA (in a PANA fashion), since the visitor would already be in position to attack at ND level. So we may want to look at existing solutions such as 802.1x, Address Based Keys, Crypto Generated Addresses, variations over PPP/PPPoE, etc... to limit or validate the L2 access a MR gives to its visitors.

In the same basic Nemo Context, we plan to tunnel home every packet, even the visitor's ones. So we'll have to consider a potential threat not only to the Mobile Network but to the home as well. 

As William mentioned "I also believe that many and perhaps most NEMOs will be mobile networks that are part of corporate intranets", home may often be a protected environment. In which case MR MUST implement the security policies of the intranet. In other words, this limits the visitors to well nown parties.

Finally, there's also a privacy aspect to consider. The global prefix of the Mobile Network could give away the MR identity just like the EUI-64 could give away visitor's identity if he used it (as opposed to RFC 3041 based address). Maybe in some cases we would tolerate to let somene's traffic through, but in an anonymous fashion for both parties (even if a third party AAA knows us both).

What do you think.?

> -----Original Message-----
> From: Takeshi TANAKA [mailto:[email-masked]] 
> Sent: vendredi 14 février 2003 02:56
> To: Alper Yegin; IETF NEMO
> Subject: Re: [nemo] AAA and NEMO
> 
> 
> 
> On Thu, 13 Feb 2003 16:34:15 -0800 
> Alper Yegin <[email-masked]> wrote :
> 
> > > For example, consider one mobile network 1 attaching to 
> fixed access 
> > > system.  Then mobile network 2 attaches to mobile network 
> 1.  Then 
> > > MNN attaches to mobile network 2.  Consider at this point that 
> > > everything is authenticated/authzed to everything.
> > > 
> > > Now, if the mobile network 1 changes its attachment point (but 
> > > mobile network 2 doesn't), will the MNN get informed about this?
> > 
> > (putting the billing issue aside) I don't think MNN needs to get 
> > informed about this. MNN gets its service from network2, 
> and it should 
> > not care where network2 or anyone up the chain gets their access 
> > service from.
> I agree.
> And vice versa, network1 cares about auth of network2, and does not 
> care about auth of MNN by network2.
> 
> > But of course MNN should have sufficient
> > trust in the network1 that it won't drag MNN into unsecure 
> corners of 
> > the Internet.
> I think, in some scenario, network1 trusts network2, but does not 
> trust(know well about) MNN in some scenario.
> i.e. network1 trusts network2, but does not know well about 
> MNN that is trusted by network2.
> 
> > And, this is  like the fixed ISP case. If your local ISP 
> changes its 
> > backbone ISP, it doesn't notify you.
> > 
> > 
> > > When mobile
> > > network 1 does its new auth/authz scheme, will it declare 
> it has the
> > > visit of the MNN which is deep beneath it?
> > 
> > With the similar reasoning, I don't think so.
> > 
> > > Will the MNN be aware of
> > > this movement of the top mobile network 1? (I mean aware 
> in terms of
> > > auth/authz.)
> > > 
> > > Maybe I don't have a clear picture about how this could work, but 
> > > maybe you have.  Again, I am in total agreement of the above 
> > > paragraph where you describe the two types of auth/authz 
> (inside and 
> > > outside). I even suggest we have that paragraph somewhere in the 
> > > requirements, if possible.
> > 
> > So, to recap: This "transparency" is a good thing. But the 
> problem is, 
> > it hides possible billing parameter changes that are 
> happening up the 
> > chain. In the above example, MR of network1 can be made 
> aware of it as 
> > part of the new AAA interaction. But either:
> > - MNNs down the chain should be immune to such changes (i.e., fixed 
> > rate), or
> > - We'd lose the transparency by introducing some accounting 
> exchange 
> > to all MNNs down the chain.  And this in general is undesirable but 
> > maybe unavoidable.
> I think the latter.
> But MNN should be notified accounting exchange only from the network 
> MNN attached to.
> 
> -----------------------------------------------
>  Takeshi TANAKA
>  R&D center, Corporate Engineering Division, 
>  Panasonic Mobile Communications
>  e-mail: [email-masked]
>  phone: +81-46-840-5494 / fax: +81-46-840-5222
> -----------------------------------------------
> 
>

---

From: Christophe Janneteau<[email-masked]>
Date: Fri, 14 Feb 2003 11:58:33 +0100

Salut Pascal,

> There's a correlated work to be done on threat analysis. You can't just let someone autoconf an address and then AAA (in a PANA fashion), since the visitor would already be in position to attack at…

Yes these threads are valid for a NEMO...as for any fixed IP subnets in
my understanding. I think these not-NEMO-specific issues are partly
addressed in other WGs (e.g. SEND) and proposed approaches should also
be applicable when the IP subnet is mobile (NEMO). In my opinion, NEMO
WG should focus on thread that are NEMO-specific...

> In the same basic Nemo Context, we plan to tunnel home every packet, even the visitor's ones. So we'll have to consider a potential threat not only to the Mobile Network but to the home as well.

I agree.
Christophe

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 Feb 2003 17:35:30 -0800

> There's a correlated work to be done on threat analysis. You can't just let
> someone autoconf an address and then AAA (in a PANA fashion), since the
> visitor would already be in position to attack at ND level.

Currently we are planning to design PANA so that it can even
operate using unspecified IP address on the client side, hence attacks based
on ND should not be an issue.

> So we may want to
> look at existing solutions such as 802.1x, Address Based Keys, Crypto
> Generated Addresses, variations over PPP/PPPoE, etc... to limit or validate
> the L2 access a MR gives to its visitors.

I think this requires same amount of work as simple node accessing the
network: initial client authentication (e.g.:PPP, 802.1x, PANA); per-packet
authentication, integrity and replay protection (e.g.: secure phy, L2
ciphers where available, IPsec otherwise), ND security (i.e., SEND).

> 
> In the same basic Nemo Context, we plan to tunnel home every packet, even the
> visitor's ones. So we'll have to consider a potential threat not only to the
> Mobile Network but to the home as well.

This is a good point. This is like a VPN.

> 
> As William mentioned "I also believe that many and perhaps most NEMOs will be
> mobile networks that are part of corporate intranets", home may often be a
> protected environment. In which case MR MUST implement the security policies
> of the intranet. In other words, this limits the visitors to well nown
> parties.
> 
> Finally, there's also a privacy aspect to consider. The global prefix of the
> Mobile Network could give away the MR identity just like the EUI-64 could give
> away visitor's identity if he used it (as opposed to RFC 3041 based address).
> Maybe in some cases we would tolerate to let somene's traffic through, but in
> an anonymous fashion for both parties (even if a third party AAA knows us
> both).

The global prefix of MR will be from the home network of NEMO.
I am missing how this might result in privacy issues...

alper