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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 13 Aug 2003 13:38:50 -0700

> 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?
> 
Why should it be a prefix ? For now, a simple address should suffice.

> 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 it is not possible to know the IP address always. In IPv6, the
node could potentially use a RFC3041 private address and hard to know
what that address would be. That's why the current pana-ipsec draft
just relies only on the link-local address in IPv6 and that's what
is bound to the selectors. If it uses tunnel mode, then the
inner addresses would be unspecified during Ipsec SA negotiation.

If we are using Ipsec or other L2 cipher for access control, the
verification
of the MIC should be enough for access control. I don't think we
have to go beyond this in PANA i.e we don't need to provide all the
details on how this can be done.

-mohan

> - 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 07:38:32 -0700

On Wed, Aug 13, 2003 at 01:38:50PM -0700, Mohan Parthasarathy wrote:
> is bound to the selectors. 

I'm not sure this is the only possible solution.  One can bind the
inner addresses to the selectors (via Identity payload exchange, or TS
payload exchange in IKEv2) and update it when an inner address changes
by re-negotiating the IPsec SA, or one can establish a distinct IPsec
tunnel mode SA for each inner address with using IKE phase 2 Identity
payload to construct the selector.

> If it uses tunnel mode, then the

If we make the issue of inner address authorization out of the scope
of PANA, then the inner addresses must be specified during IPsec SA
negotiation.  I am considering this method.

If we make the issue of inner address authorization in the scope of
PANA, then the inner addresses do not need to be specified during
IPsec SA negotiation, but additional access control for the inner
addresses will be needed outside the framework of IPsec.  In this
case, inner addresses should be used as PANA DI and communicated to
the EP, as Dan is suggesting.

> of the MIC should be enough for access control. 

From the viewpoint of access control this is not enough.  As Dan 
pointed out, authenticated attacker can spoof other authenticated 
clients' inner addresses.  I think this should be prevented.

> I don't think we

I think we need more discussion for the PANA-IPsec draft on the 
inner address authorization issue.

Yoshihiro Ohba