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

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

> > > 
> > 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.
> 
> 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.

So, I can put in any address and the other end will accept it ?
Note that we are talking about tunnel mode Sas and the addresses
we are negotiating are inner addresses. If I can put in any address
for the inner address and the other end will accept it, then
we have not solved the problem yet. If you want to know whether
I am authorized to use a particular address, you need SEND.
In mobile IP, the home agent needs to maintain a table of
ID - address, and it verifies this during the Ipsec SA setup
whether the address specified in the traffic selector can
be used by this ID. You need 

> 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.  
> 
IKE responder address is DI - the link-local address. You still
cannot possibly not know all the addresses the Pac will use.

> > 
> > > > 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 ?
> 
> 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.

How do you authorize the use of a given IP address using IKE or IKEv2 ?

-mohan

> 
> > 
> > > 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.
> 
> 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.
> 
> > 
> > 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.
> 
> This might be a way, if that is enough to maitain 
> interoperability, but I'm not sure.
>
> 
> > 
> > > > 
> > > > 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
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 18 Aug 2003 14:13:05 -0700

On Thu, Aug 14, 2003 at 11:47:40AM -0700, Mohan Parthasarathy wrote:
> we have not solved the problem yet. 

You are right.  I haven't thought of it.

> If you want to know whether

Yes, if the IKE responder accepts only the inner IP addresses for
which ownership is proven by the use of SEND, we are done, given that
both inner and outer addresses should use the same 64-bit interface
ID.

Yoshihiro Ohba