Subject: RE: RE: draft-ietf-pana-usage-scenarios-00.txt

From: George Tsirtsis <[email-masked]>
Date: Thu, 7 Feb 2002 09:12:43 -0500

Hesham,

The NAI/IMSI is fine to uniquelly identify the thing you are authenticating
and we actually require this and expect the NAI to be the default PaC ID.

The idea was, however, that the DI should be something that for example the
Access Router can check on a packet by packet bases. That is the only way to
police what you have authorized...and that is why I think DI has to be
defined by the PAA/AAA only at this stage.

see what I am saying?

George

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 2:06 PM
To: 'George Tsirtsis'; Hesham Soliman (ERA)
Cc: [email-masked]
Subject: RE: RE: draft-ietf-pana-usage-scenarios-00.txt

George,

  > I think it would be nice to have a *default* DI that 
  > everyone supports. A
  > good one would be the IP address of the end node. The 
  > problem is that as we
  > have discussed a lot of times, PANA may happen before 
  > address allocation in
  > which case we are in trouble. For this reason I always 
  > thought (personal
  > rather than design team opinion) that the DI should not be 
  > carried in PANA.

=> Sure, but we could say that the protocol MUST 
support 2 types of DI, e.g. NAI and IMSI
and MAY support x, y ,z as well.

Using an IP address is not gong to be flexible because
we need to allow for privacy, monet ...etc

  > Instead the PAA will need to know what the DI is and use 
  > whatever mechanism
  > it has to authorize traffic with it (install an access 
  > filter in an access
  > router) i.e.: DI is just a *hook* for authorization.

=> Sure.

  > 
  > Now in the future, we may want to think about DI 
  > negotiations were the MN
  > requests access to a potentially complex set of DIs (IP 
  > addresses, port
  > numbers, mcast services, QoS levels etc) and the network 
  > accepts some,
  > reject some others etc etc. This would add Access Control 
  > capabilities to
  > the PANA protocol.

=> I'm not sure that 'src IP addresses' should 
be considered at all.

  > 
  > For good reasons, we currently have Access Control as being 
  > out of scope of
  > PANA and I think this is a good thing. Access Control is 
  > powerful but also
  > very complex and a bit of a can of worms like capability 
  > discovery partly
  > because no one is actually doing it between the end node 
  > the network but
  > only between the AAA server and the access router. By 
  > limiting PANA to
  > *authentication* and providing a hook for authorization it 
  > is more likely
  > that we will come up with a good solution that does on 
  > thing well. Then we
  > can have long and interesting discussions about how to 
  > extend the protocol
  > or how to add functionality in a nice, modular way.

=> I have no problem with that, I only 
want to see an access independent, IP address
independant identity for authentication,
authorisation. How access control is done 
after that is something that we can discuss. 
(I thin it's possible). But we need to find
the right architectural base for the first 2 A's.

Cheers,
Hesham

  > 
  > 
  > 
  > -----Original Message-----
  > From: Hesham Soliman (ERA) [mailto:[email-masked]]
  > Sent: Thursday, February 07, 2002 1:24 PM
  > To: 'George Tsirtsis'; Hesham Soliman (ERA)
  > Cc: [email-masked]
  > Subject: RE: RE: draft-ietf-pana-usage-scenarios-00.txt
  > 
  > 
  > 
  > 
  > 
  > > Who says that the DI is *access dependent*? 
  > 
  > => Not me !
  > 
  > It MAY be, 
  >   > true, but it does not
  >   > have to be. We currently only say that the DI MAY be 
  >   > carried in PANA so it
  >   > is not mandatory for a solution to do it. We also say that 
  >   > the DI is a kind
  >   > of handle that access control can use to authorize some 
  >   > traffic. The DI
  >   > could be as simple as an IP address or a link layer port 
  >   > number if such
  >   > thing is used in a given scenario but it could potentially 
  >   > be other things
  >   > as has been discussed.
  > 
  > => Phew... that's a relief. 
  > FWIW I think we MUST specify who is being 
  > authenticated/authorised. It is not enough to
  > reserve a field in the protocol and say 'here
  > you can carry whatever you like'. 
  > Access independence is crucial here, so there is
  > nothing wrong in saying that the DI (if you want to
  > call it that) 'MUST NOT be access dependant' like 
  > a MAC address for a certain link layer ...etc.
  > You can have options to carry additional
  > system dependant parameters (for tracking stolen
  > devices perhaps) but they should be in addition
  > to the generic identifier.
  > 
  > 
  > 
  > 
  > Hesham
  >