Subject: Security threat (was: RE: [issue9] Message format)

From: <[email-masked]>
Date: Mon, 23 Jun 2003 14:44:28 +0300

Alper,

I had one week vacation and thus the answers are a bit 
late. Here are my comments.

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 11 June, 2003 22:04
> To: Forsberg Dan (NRC/Helsinki); [email-masked]
> Subject: Re: [issue9] Message format
> 
> 
> >>> What if the MN wants to access the local network with link
> >> local or site local
> >>> addresses at the same time with a global CoA address?
> >> 
> >> We have discussed this. Depending on the DI:
> >> 
> >> - if MAC address: then there is no issue. PaC can configure any
> >> IP address on the specified MAC address. Access control is based on
> >> the MAC address.
> > 
> > Where is this kind of scenario feasible?
> 
> In scenarios described in sections 4.1 and 4.2 of the usage 
> scenarios draft,
> plus 4.3 where link-layer ciphers are enabled at the end of PANA.
> Effectively, almost anywhere IPsec is not used for access control.

What if the authenticated PaC itself becomes malicious? It can blindly 
spoof other PaCs addresses. This is a security threat, even if the MAC 
address is bound to accounting.

> 
> > 
> > That would mean that PaC can freely spoof IP addresses.
> 
> Exactly. But, this is a SEND problem, not PANA problem.

This problem goes beyond SEND and even IPSec. SEND is for discovery 
only, not for protecting data packets like IPSec. On the other 
hand IPSec is used for protecting malicious users from stealing 
other's connections on the access link, right? Or should we say 
that IPSec is used for making sure that only "paying" customers 
can send packets.

The access network doesn't want the PaCs to be able to spoof 
network nodes that are inside the access network (behind the 
first AR). What the EP wants to do is to make sure that the 
packet coming from PaCs has an IP address that belongs to the 
correct subnet prefix (access link prefix). By default the 
policy in the EP (in most cases) is to deny all IP addresses 
if not authenticated AND authorized properly.

The problem is authorization of data packets that pass through 
the EP. IPSec takes care of authentication (SEND doesn't do 
neither).

With IPSec tunnel between PaC and PAA, the inner IP address 
MUST be checked too! Otherwise authenticated and authorized 
PaCs can spoof IP addresses.

> 
> > I don't think it's a
> > good idea. Filtering should be based on IP addresses as 
> well. PANA is IP level
> > protocol..
> > 
> >> - if IP address: This is the case where IPsec is used. For 
> this, PaC
> >> determines one of the IP addresses as DI, most probably a 
> link-local
> >> address. The traffic is tunneled using this DI as the local
> >> end point. See
> >> PANA-Ipsec draft. Now, if the PaC wants to use other IP
> >> addresses, they
> >> will be used only within the tunnel, hence the access 
> control does not
> >> care about them.
> > 
> > If DI is IP address, IPSec is not always used (physically 
> secure links for
> > example or links that provide L2 protection). Right?
> 
> If we are not using IPsec,it does not make sense to use IP 
> address as the
> DI, unless we are trying to solve SEND problems here. We should use
> lower-layer identifiers.

See my comment above.

> 
> > 
> >> 
> >>> 
> >>> What if the MN has multiple interfaces (WLAN, Bluetooth,
> >> Ethernet, 3G, etc.)
> >>> that all get a separate IP address from the same NAP
> >> through the same PAA?
> >>> It's better to have one PANA session but add/delete
> >> addresses/interfaces.
> >> 
> >> The simple answer is: all physical interfaces should do PANA
> >> independently.
> >> Is there a problem with that?
> > 
> > This is not a good approach. Just think about the re-auth 
> message flood,
> > multiple session state information and even possibly 
> multiple AAA backend
> > sessions on the core network. Not scalable. Consumes 
> resources on the client
> > and on the network unnecessarily.
> > 
> > Another point is that adding new interface to the existing 
> session is faster
> > than doing the whole AA process from scratch.
> 
> You are talking about room for possible optimizations, not problems.
> I suggest we open this as a new issue, and follow it up from 
> there. Rather
> than continuously optimizing the basic design. I think such 
> optimizations
> touch more than the PANA design, so we should do a more 
> thorough analysis.

Ok. I've created a new issue 16.

- Dan

> Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 23 Jun 2003 10:10:43 -0700

Dan,

A couple of comments below...

> address is bound to accounting.

I agree with Dan on this.

> that IPSec is used for making sure that only "paying" customers 

Yes, SEND and IPsec solves different problems.  One does not cover the
other.

> PaCs can spoof IP addresses.

The inner address checking is a task of IPsec.  In addition, since
inner addresses can be carried in ID payload in IKE and Traffic
Selector payload in IKEv2.  PANA Device-Id AVPs do not need to carry
inner addresses.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 23 Jun 2003 11:38:28 -0700

Hi Dan,

> address is bound to accounting.

I agreed :) I'm not disagreeing with the security threat here. I'm
disagreeing with the assumption that this is a problem that *must* be solved
by PANA. Let's first agree (or disagree :) on that. Note that this does not
mean PANA *must not* solve it. PANA may solve it, or PANA may assist another
protocol solve it, etc... But we need to thoroughly understand the problem,
and its relation to existing/upcoming solution space.

> only, not for protecting data packets like IPSec.

I agree this is beyond SEND, according to SEND's current scope. But it is
the closest to what SEND is aiming: proving ownership of IP address for
address resolution. It's only reasonable to assume that the next step could
be proving ownership of IP address for sending IP packets.

> On the other 

PANA deals with authorizing a Pac to send and receive packets. That's all.
PANA does not deal with any other authorization.

That does not mean that these are all the problems that needs to be solved
to make an access network 100% secure.

Alper