Subject: RE: Issue4: (new) Device identifier (types)

From: <[email-masked]>
Date: Thu, 14 Aug 2003 11:18:21 +0300

Let's face the problem. If we don't bind the global 
IP address to the PANA session, PaC is able to spoof 
all the other (possibly authenticated) clients (and 
in the worst case even network elements etc.).

If you say this problem is out of scope of PANA, I don't
agree with you. This is a question that needs to be 
resolved in a standard. Otherwise vendors will do 
something by their own.

In short, PANA MUST provide support for IP address 
spoofing prevention both with L2 and L3 ciphering, or 
without ciphering at all. Otherwise we have a serious
security problem.

Since PANA has a SA and thus supports authenticated 
messages between PaC and PAA, it is a proper protocol
to use for IP address spoofing prevention.

- Dan

> -----Original Message-----
> From: ext Mohan Parthasarathy [mailto:[email-masked]]
> Sent: 13 August, 2003 23:47
> To: Yoshihiro Ohba; Forsberg Dan (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: RE: Issue4: (new) Device identifier (types)
> 
> 
> 
>  
> > 
> > On Wed, Aug 13, 2003 at 05:01:45PM +0300, 
> > [email-masked] wrote:
> > > One of the questions in IETF57 PANA wg meeting was that should PAA
> > > take care of authorizing IP addresses. I think it should, because 
> > > it informs the EPs about the filtering rules.
> > > 
> > > If I've understood correctly IPSec tunnel is used between PaC and
> > > EP/PAA with link local addresses. Then the inner IP 
> address in the 
> > > IPSec tunnel should be PANA DI. In this case it could be a subnet 
> > > prefix, right?
> > 
> > The inner IP address in the IPsec tunnel is not necessarily 
> > be a PANA DI, since the outer IP address (i.e., a link local 
> > IP address) can be used as a PANA DI.  Authorization for the 
> > inner IP address can be done in IKE negotiation by which an 
> > appropriate per-packet filtering rule for the inner IP 
> > address is set to IPsec SPD.  IKE also supports negotiatin of 
> > subnet-prefix parameters for inner packets.
> > 
> It is not possible to know the inner IP addresses always i.e the
> dynamic SPD setup should be very simple. Just use the DI (link-local
> in IPv6 or the DHCP address in IPv4) for binding to the Ipsec SA.
> 
> > 
> > > 
> > > If PANA uses MAC as the DI (and even with IPSec tunnel), 
> > PAA/EP can't
> > > control the IP addresses the PaC is using (inner IP 
> address in the 
> > > IPSec tunnel). Anyway, I firmly believe that access 
> networks wount 
> > > pass packets with ANY source IP address to the network 
> (refusal to 
> > > route). So I don't think that any IP address can be used 
> inside the 
> > > IPSec tunnel.
> > 
> > I think the required functionality of per-packet filtering 
> > for inner packets is already covered by the combination of:
> > 
> > - Support of DI update (from MAC address to IP address).
> > 
> > - Use of link-local address as a DI when bootstrapping IKE.
> > 
> > - Use of IKE for establishing an tunnel mode IPsec SA between 
> > PaC and EP.
> >   (as a result, an SPD entry for inner packet filtering will 
> > be created.)
> > 
> As I mentioned in other mail, we don't need this. We are talking
> about access control. MIC is sufficient for authorization. 
> 
> -mohan
> 
> > - Use of IPsec tunnel (whether inner packet filtering is done
> >   based on the created SPD entry).
> > 
> > 
> > Yoshihiro Ohba
> > 
> > 
> > > 
> > > - Dan
> > > 
> > > > -----Original Message-----
> > > > From: ext Alper Yegin [mailto:[email-masked]]
> > > > Sent: 08 August, 2003 00:42
> > > > To: [email-masked]
> > > > Subject: Issue4: (new) Device identifier (types)
> > > > 
> > > > 
> > > > 
> > > > http://www.danforsberg.info:8080/pana-issues/issue4
> > > > 
> > > > The issue text refers to multi-homed hosts and device ID
> > > > changes. These are
> > > > covered under separate issues (#16 and #5).
> > > > 
> > > > So, issue #4 should only be talking about new DI types. 
> > And the one 
> > > > mentioned in the text is "subnet prefix." Unless anyone 
> > has another 
> > > > proposed device ID type, let's discuss that.
> > > > 
> > > > I'm trying to understand the utility of setting the DI as a
> > > > subnet prefix.
> > > > If this is proposed to enable mobile routers to connect 
> > to an access
> > > > network, we can easily achive that by using either a mac 
> > > > address DI along
> > > > with L2 ciphering, or a single IP address DI along with 
> > > > IPsec. In the latter
> > > > case, any IP address can be used inside the IPsec tunnel. 
> > > > Aside from not
> > > > needing it, I'm also not sure how we can use this DI as an 
> > > > IPsec end point.
> > > > 
> > > > Unless anybody objects, I recommend we reject this issue.
> > > > 
> > > > Comments please.
> > > > 
> > > > Alper
> > > >  
> > > > 
> > > > 
> > > 
> > 
> > 
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 12 Aug 2003 08:06:19 -0700

> in the worst case even network elements etc.).

I agree that inner address spoofing by authenticated attacker is a
threat for the network access security.  However, I don't think using
the global IP address in addition to link local address is the only
way to prevent the attack.

As I mentioned in other email repled to Mohan, if inner address
authorization is done in IPsec SA negotiation (and I think it can),
the global IP address does not need to be directly bound to the PANA
session and IPsec can perform inner address filtering based on the
authorization result.

> resolved in a standard. Otherwise vendors will do 

I agree that this needs to be resolved in a standard.  But what I
don't understand is why we can't rely on the functionality of IPsec
for inner address authorization and resulting access control based on
SPD.

> without ciphering at all. Otherwise we have a serious

Except for the following case: If neither L3 ciphering is used nor the
lower-layer is physically secured, it is not possible to prevent IP
address spoofing by authenticated attackers.

> to use for IP address spoofing prevention.

I believe IPsec is the proper protocol to use for IP address spoofing
prevention.  What PANA must do for this is to bootstap IPsec.

Yoshihiro Ohba