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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 14 Aug 2003 10:11:54 -0700

> 
> On Wed, Aug 13, 2003 at 01:38:50PM -0700, Mohan Parthasarathy wrote:
> > > 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.
> 
> 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.
> 
How does the EP know about these selectors ? Before the Ipsec
negotiation starts, the other end should have a configured
SPD entry for the addresses that you specify in the traffic
selector. Tell me how the EP knows about these addresses.

> > If it uses tunnel mode, then the
> > inner addresses would be unspecified during Ipsec SA negotiation.
> 
> 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.
> 
I am not sure I understand this. Could you rephrase ? If it outside
the scope, then why specify any inner address at all ?

> 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.
> 
I am not sure I understand this detail.

Note that if someone wants to use Ipsec for preventing the spoofing
problem, then it is fine. I just have one question mentioned above.
All  I am saying is we don't need to go in to a lot of details
explaining
how to do it. Perhaps we can mention briefly the issue in security
consideration.

> > 
> > If we are using Ipsec or other L2 cipher for access control, the 
> > verification 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.
> 
Why ? The client is authorized to use the network if he has the
right key. Yes, we can do lots more. I am still not convinced
that this is in the scope though.

> > 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.
> 
> I think we need more discussion for the PANA-IPsec draft on the 
> inner address authorization issue.
> 
Ok. Let us have the discussion here first as to what issues we need
to solve. I am missing the requirements on this.

-mohan

> Yoshihiro Ohba
> 
> 
> > 
> > -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 09:46:38 -0700

> selector. Tell me how the EP knows about these addresses.

The selectors can be dynamically negotiated by using IKE or IKEv2.  Though
some IPsec implementation may configure SPD IPsec negotiation, there
is basically no need to have SPD configured before IPsec negotiation
starts.  As I mentioned above those inner addresses can be known by EP
(which is an IKE or IKEv2 responder in this case) via IPsec SA
negotiation through IKE or IKEv2.  

> the scope, then why specify any inner address at all ?

Let me rephrase this:

  If we make the issue of inner address authorization out of the scope
  of PANA *protocol*, then the inner addresses must be communicated from PaC to
  EP and authorized by the EP through IKE or IKEv2.

> I am not sure I understand this detail.

Let me rephrase this:

  If we make the issue of inner address authorization in the scope of
  PANA *protocol*, then the inner addresses do not need to be
  communicated from PaC to EP through IKE or IKEv2, 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.

> how to do it. Perhaps we can mention briefly the issue in security

This might be a way, if that is enough to maitain interoperability,
but I'm not sure.

Yoshihiro Ohba