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

From: <[email-masked]>
Date: Fri, 15 Aug 2003 10:37:57 +0300

Mohan,

Here are some references to the requirements document.

draft-ietf-pana-requirements-07.txt:
   4.1.2. Authorization, Accounting and Access Control  
     
   After a device is authenticated using PANA, it MUST be authorized 
   for "network access." That is, the core requirement of PANA is to 
   verify the authorization of a PaC so that PaC's device may send and 
   receive any IP packets.

draft-ietf-pana-requirements-07.txt:
   4.4. PAA-to-EP Protocol 
    
   PANA does not assume that the PAA is always co-located with the 
   EP(s). Network access enforcement can be provided by one or more 
   nodes on the same IP subnet as the client (e.g., multiple routers), 
   or on another subnet in the access domain (e.g., gateway to the 
   Internet, depending on the network architecture). When the PAA and 
   the EP(s) are separated, there needs to be another transport for 
   client provisioning. This transport is needed to create access 
   control lists to allow authenticated and authorized clients' traffic 
   through the EPs. PANA Working Group will preferably identify an 
   existing protocol solution that allows the PAA to deliver the 
   authorization information to one or more EPs when the PAA is 
   separated from EPs.

Authorization for "network access" includes IP address authorization. 
The requirements spec (above) says "-- so that PaC's device may send and
receive any IP packets". My interpretation about this is that in the 
beginning PaC is able to communicate only to the PAA, but after 
authentication and authorization PaC is able to really access the 
Internet.

Also, PAA needs to have the info of PaC's IP address(es) for PAA-to-EP 
protocol to carry it to the EP that really needs this info for 
access control.

So, this really is in the scope of PANA.

- Dan

> -----Original Message-----
> From: ext Mohan Parthasarathy [mailto:[email-masked]]
> Sent: 14 August, 2003 20:03
> To: Forsberg Dan (NRC/Helsinki); [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Issue4: (new) Device identifier (types)
> 
> 
> 
> > 
> > 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.
> > 
> Please point to me where in requirements is this specified ?
> At least I don't remember reading one.
> 
> The important goal of the working group is to specify PANA
> protocol. And we also agreed that we will come up with some
> mechanism to provide access control. We are documenting
> one way of doing this i.e using Ipsec. Now we can keep
> adding more to this list. We can explore to see if we
> can use Ipsec to solve all the problems. But is this
> really in scope ? If Ipsec solves it for free, then it
> is fine. But I still strongly feel that it is not in
> the scope.
> 
> -mohan
> 
> > 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: Alper Yegin <[email-masked]>
Date: Fri, 15 Aug 2003 16:48:42 -0700

> Authorization for "network access" includes IP address authorization.

No it doesn't. As we specifically said, this is all about "being authorized
to send *any* IP packets", not "authorized to use an assigned IP address for
sending and receiving IP packets". You are getting into finer granularity
authorization which we explicitly kept out-of-scope.

> authentication and authorization PaC is able to really access the

Yes, and that still does not have anything to do with "IP address
ownership". 

> protocol to carry it to the EP that really needs this info for

EP needs to know only one IP address when IPsec is used for access control.
And this is the IP tunnel end point on the PaC. This is sufficient for
ensuring "only authorized hosts access the network."

> So, this really is in the scope of PANA.

I disagree. 

I'm not disagreeing that IP address spoofing is a problem. But, clearly this
is an out-of-scope problem for PANA protocol. If one can solve this by using
some IKE features, that's fine. But putting the burden on the PANA protocol
design is not right.

Alper