Subject: RE: Location of authentication agent

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 15 Apr 2002 18:10:57 +0200

Subir, 

Yes. 

Hesham

  > > => Well, it depends on which case you refer to. In the
  > > load sharing case you need to separate the access
  > > enforcement from the authentication, otherwise you
  > > need to authenticate twice (unless there is some
  > > protocol running between the default routers).
  > 
  > 
  > If I understand you correctly, following are the abstractions:
  > 
  > For limited free access:
  > 
  > PANA Client ------- Edge device -------- Enforcement 
  > Point/PANA Agent
  > ------ PANA Server
  > 
  > 
  > For Load sharing:
  > 
  > PANA Client ------ Edge Device/Enforcement Point ---- PANA 
  > Agent ------
  > PANA Server 
  > 
  > 
  > Subir
  >

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 17 Apr 2002 04:47:09 +0200 (CEST)

> I like to think of it as starting from the most flexible
> solution, then trading flexibility for cost. 

Given that the BoF is in serious need of focus I'd advocate the
opposite approach.

Start with the minimal thing. Determine whether or not this minimal thing
is useful by folks that think PANA will be useful.
Use this to motivate strongly what needs to be added to the minimal thing
until there is something which several people think is useful enough
to consider including in future products.

> There were concerns raised during the meeting about 
> the 'extra cost' associated with this separation, 
> but I didn't get a clear idea about where this cost
> would come from. So maybe now is a good time to
> discuss this. 

With the above approach the onus for motivating additions would be on those
proposing additions, which is likely to lead to less complex solutions.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 17 Apr 2002 04:46:49 +0200 (CEST)

> => More than the ones in the scenarios draft?
> Namely: Load sharing, limited free access and 
> payment after a certain point..etc

If I understand "load sharing" I think you can do this with a
single PANA entity load sharing over multiple local AAA servers.

I've had a hard time understanding the user interface issue in the
"payment after a certain point".
If an operator is going to provide different rates for "local" and "remote"
access with the "remote" being usage-based (either connect time or
packets/bytes) I as a user would certainly want to know when I'm being
billed based on usage or not including having the ability to terminate
the "remote" access.

A possible way to make this visible to the user is to use different
"login names" (NAI) for the two cases.
Thus if I login as "room123@hotel" I get the free local access.
To get Internet access I login as "[email-masked]".
This would give me the ability to logout from the internet access session
and stop being charged.
And this doesn't require more than one PANA entity in the network - the PAA
could be in the access router (or anywhere else).

As I understand the "payment after a certain point" with a split PANA entity
it would detect that packets are flowing towards the Internet and
at that point ask my device to authenticate itself i.e. the network
initiates that action. Will the network also initate loggin me out? Or
does the user need to do that?
How can the network reliably tell that my device has no existing
communication with the Internet?

Trying to understand,
  Erik

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 17 Apr 2002 10:59:28 +0200

> > I don't know if someone has a better idea on how
  > > to do this. Of course the other question is: Why 
  > 
  > So, the idea is to build a hierarchy of authentication.

=> No there is no need for any different hierarchy
from the configuration you mention.

  > If the PaC gets authenticated to a PAA behind a set of
  > access routers, we expect the PAA to automatically 
  > distribute state to all access routers within this PaC's reach.

=> Does this work for the limited free access scenario?

  > > does it matter? That is, what is the cost incurred
  > > in separating the 2 entities and running SNMP/COPS/midcom ...etc
  > > between them ?
  > 
  > We'd need to identify what that transport is, and make sure 
  > it satisfies
  > all the needs of access authentication (transporting keys?)

=> Yes. 

  > 
  > The PAA discovery would be different as well, and harder I suspect.

=> No I don't think so. I can't even say it's different
because there is no idea presented on how
to discover an on-link PAA. Unless you assume (mandate) 
that every router in the world has to implement
a PAA.

  > A better approach is starting simple and seeing if it can
  > serve the need. If not, expending on it, IMO.

=> Why is this better? 
Also I could agree with your approach but it
doesn't always work like that. If we make 
the assumption that the off link PAA
is not important for now, people are most 
likely to ignore the 'for now' part and limit
the design to the on-link case. I'm not being 
paranoid, given the existing division in the 
WG and existing proposals, this is very likely
to happen. Which is why I hate talking
about solutions before the requirements are
finished.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 17 Apr 2002 11:05:56 +0200

> Whatever is used currently between a NAS and other routers 
  > on the link
  > would work for a PAA as a NAS.
  > 

=> Routing protocol security is _completely_
different from other IP security mechanisms.
You can't assume that just because RIP or BGP
are secure, the two _routers_ would have an SA
to secure other traffic.

Hesham

  > ----- Original Message -----
  > From: "Yoshihiro Ohba" <[email-masked]>
  > To: "James Kempf" <[email-masked]>
  > Cc: "Yoshihiro Ohba" <[email-masked]>; "George Tsirtsis"
  > <[email-masked]>; "Hesham Soliman (ERA)"
  > <[email-masked]>; "Alper E. YEGIN"
  > <[email-masked]>; <[email-masked]>
  > Sent: Tuesday, April 16, 2002 4:35 AM
  > Subject: Re: Location of authentication agent
  > 
  > 
  > > On Mon, Apr 15, 2002 at 02:58:41PM -0700, James Kempf wrote:
  > > >
  > > > > The number of LSAs is not a problem at all since LSAs are
  > dynamically
  > > > > established.  The SAs between routers are static ones and that
  > would
  > > > > increase management complexity, I think.
  > > > >
  > > >
  > > > LSA means "Link State Advertisement". It is the reachability
  > information
  > > > that is exchanged between routers. If a network operator is
  > concerned
  > > > about security, they will enable cryptographic security on their
  > router
  > > > traffic. If they are offering public access service and require
  > PANA,
  > > > then it makes a certain amount of sense that they do.
  > > >
  > > > Regarding the SAs being static, what's the problem? The 
  > routers can
  > use
  > > > Kerberos, IKE locally, or AAA to obtain keys, so the key
  > distribution is
  > > > taken care of. Of course, the network operator must 
  > enable that, but
  > the
  > > > same steps are needed for a separate PAA if you want to use
  > Kerberos,
  > > > IKE locally, or AAA for PAA key distribution.
  > >
  > > OK, static SA will not be the problem.  Do you assume 
  > using the same
  > > SA for securing Link State Advertisement and securing 
  > SNMP?  If you
  > > don't necessarily assume that, I don't still understand why
  > > co-location is simpler than separation.  Moreover, it 
  > seems to me that
  > > allowing SNMP 'set' operation mutually among access routers is
  > > difficult to manage.
  > >
  > > Yoshihiro Ohba
  > >
  > >
  > > >
  > > >             jak
  > > >
  > > >
  > >
  >

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 17 Apr 2002 11:09:35 +0200

> I agree we need another protocol, but the protocol is
  > already out there. Actually we have more than one to
  > choose from: COPS, midcom, snmp...
  > 
  > Let me ask this. Can't we say PAA and EP can be on
  > different devices or on the same device. If they are
  > on different devices you need a protocol between them,
  > which is out of scope. period.
  > 

=> Amen!

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 17 Apr 2002 11:13:52 +0200

> It need not be RADIUS or Diameter but there does need to be 
  > something.
  > 

=> No. A hotel doesn't have to be connected to any
AAA infrastructure to give you access to the Internet.
A local shared secret will do, like your room number!

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 17 Apr 2002 11:27:05 +0200

> single PANA entity load sharing over multiple local AAA servers.

=> Is this for the multiple AR case? I didn't understand
what you meant.

  > billed based on usage or not including having the ability 

=> Well, if you're in a hotel, they might tell you 
when you check in (in some way) that you can use the
'local' Hotel servers for free, but anything else you need
to pay. The same in an Airport lounge, you could check
flight information, or other airport stuff for 
free, but anything else you need to pay. They can inform
you when you check in for example.

  > "login names" (NAI) for the two cases.

=> Sure, but you could also have a filter somewhere 
in the network (where if you cross it, you would have
to pay).

  > could be in the access router (or anywhere else).

=> Yes, that can be done.

  > does the user need to do that?

=> I think that we should have a requirement
for network initiated login (useful for re-authentication)
and host initiated login. (sorry for the messay terminology
but I think you will know what I mean ;) )
This is important regardless of the placement of the 
PAA IMHO.

  > communication with the Internet?

=> Hmm, nice question!
I suppose it depends on how you're getting charged.
If you're charged by time, then your device would
have to log you out after DEFAULT_IDLE_TIME perhaps.
If you're charged per packet, then there would have 
to be a router (probably the same PEP that detected 
you were not authorised to go any further) that
counts packets. This is my initial attempt, so
there are probably some details missing.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 17 Apr 2002 13:11:29 +0200

> This is just the sort of thing I was afraid of.
  > We should find out as soon as possible if the WG
  > wants PANA to be designed so that it supports
  > walled gardens. The walled garden is about as
  > antithetical to the fundamental principles of the
  > Internet as anything I have seen.

=> I don't think Reinaldo meant the same thing. 
Limited free access is another name (probably
a bad one too). But it's definitely not a 'walled
garden'. 

Hesham

---

From: <[email-masked]>
Date: Fri, 19 Apr 2002 10:47:52 -0500

James,

> Right, but the attacker can still continue to pump PANA packets at the
> PAA.

There are mechanisms for preventing such flooding of PANA messages to
a certain degree. But stopping DoS attacks completely is not a possibility.
The same argument about an attacker doing DoS attacks is valid for the
L2 mechanisms. So while what you say is true, I consider this just as a 
requirement for PANA.

>             jak

Basavaraj

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 22 Apr 2002 12:15:24 +0200

> Seems like I didn't understand "load sharing".
  > Is load sharing in this context having a single device use 
  > multiple ARs?

=> That was the intention, yes. Something that
allows for Bob Hinden's load sharing draft.

  > Yes. But just because I looked at www.dn.se on Monday I 
  > don't want to be
  > charged for Internet access for the whole week.
  > How can I as a user know that I've "logged out" from the 
  > Internet access
  > part of the network and have reverted to only using the 
  > free local info
  > part of it?

=> There are lots of different considerations here
I think. I haven't thought of a solution but I can
list my initial thoughts and let me know where it
might be unrealistic or undoable. 
The first question is why does the user need to know?
A reasonable answer is that the user wants to know
what he/she are paying for. But this depends on
the charging model. So if they're charge by time,
there can be a default idle time, after which the
PaC logs the user out. In this case the use might
get some indication from a GUI (just like a modem
logs a user out after a set idle time). This 
is the same issue for modems operating in countries
where a phone call is charged by time, or when
using a mobile phone for a dialup connection.

If the user is charged by the number of packets,
then logging out is not an issue. Perhaps the
way the charging is done can be communicated 
during 'login'.

The third option is flat rate, in which case
re-athentication will be done, say every 24
hours, as is the case in some hotels today.

Does that address your question?

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 22 Apr 2002 12:15:57 +0200

James,

  > > 1. I just haven't been able to understand why
  > >    minimal means on-link PAA. I could understand 
  > >    it more if there is a clear decision to eliminate
  > >    the scenarios that won't work because of this 
  > >    decision. But perhaps people think all scenarios 
  > >    will work anyway. This might be clear by further 
  > >    discussions.
  > > 
  > 
  > The scenarious should be checked that they work, of course,
  > but if the existing NAS architecture works then why change it?

=> I didn't suggest changing anything, but at this
time, our understanding says that to satisfy the 
scenarios documented, we need to separate the 
AA from PE in _some_ cases.

  > > 2. People will do the minimum without leaving any
  > >    room for the additions. I think this is a very
  > >    likely case. 
  > > 
  > 
  > What is wrong with just doing something simple?

=> Simple and meets requirements is Great.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 22 Apr 2002 12:16:55 +0200

>   > I wasn't saying that the working group should only work on 
  >   > some minimal
  >   > thing. 
  >   > 
  >   > I was suggesting a *process* by which the WG can better 
  > understand
  >   > what is the minimum thing they can do and still end up with 
  >   > something
  >   > that some number of people are interested in.
  >   > 
  >   > Without this process I don't see how the WG can obtain focus.
  > 

 => I fully agree. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 24 Apr 2002 10:22:18 +0200

> 
  > Hesham, in addition to showing how this would work with separation,
  > we still need to see how it doesn't work with co-location.

=> Sure, it would be good if we share ideas on how
this could really work when the PAA is on-link.
Note that I don't assume that there is always 
a backend AAA infrastructure.

  > 
  > Furthermore, we also need to understand how important of a problem
  > this is to solve.

=> This is a grey area. Very little engineering
here and lots of speculation. I'd rather not go
there.

  > 
  > If this can be solved by locating PAA one hop away from
  > the PaC, then no problem (already covered). When on the same
  > link as PaC, if we still need to separate PAA from EP, this 
  > is still OK,
  > and we'd like to keep the additional transport between two outside
  > the scope of PANA (see the FAQ).
  > 
  > The goal is to define the minimum scope for PANA that
  > is useful and can solve important/essential problems.

=> Sure. 

Hesham

  > alper

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 24 Apr 2002 10:24:31 +0200

> > > Based on the discussion, this seems like one way to use
  > > > PANA. But of course it relies on an out-of-band PAA discovery.
  > >
  > > What does the out-of-band PAA discovery mean in this case?
  > 
  > Normally, PAA is assumed to be on the same link as PaC and
  > PANA will define a PAA discovery method.
  > 
  > But since in this particular usage, PAA is not on the same link
  > as the PaC, this discovery method won't work. Instead some
  > other mechanism/protocol should provide the identity of
  > new PAA.
  > 
  > An example is that PaC knows its geographic location
  > (via GPS) and has a table with AP/PAA locations. Now it can do
  > a simple lookup and discover the upcoming PAA(s).
  > [disclaimer: this is just an illustration of out-of-band PAA
  > discovery and absolutely outside the scope of PANA :) ]
  > 

=> Or even PAA.localdomain.X can be done. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 24 Apr 2002 10:18:40 +0200

> I think I stated this before. Let me try again.
  > *Unless* you are going to ban/forbid/outlaw billing based 
  > on "connect time"
  > the approach taken MUST provide a mechanism by which the 
  > user is certain
  > that it has "disconnected" from the service that uses such billing.

=> Agreed. My text above was an attempt to show
one way of doing it. But as you say below
the solution would need to take this into account.

  > 
  > Thus the complexity of wanting to support some things being free and
  > other things not being free means that there needs to be an 
  > approach for
  > how to handle this. Note that this doesn't mean that any 
  > protocol is needed -
  > but the approach to solving the problem needs to take this into
  > account. 
  > 
  > So as long as the PANA usage scenarios document talk about this
  > case and it remains (significant) motivation for a requirement
  > that the PAA be separable from the access control enforcement point,
  > then I think we need to continue to explore this space 
  > until there is
  > an answer.

=> Agreed.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 25 Apr 2002 16:54:59 +0200

> If it's all speculation on how this would be used then I think it
  > is pretty clear that it isn't an important enough problem to solve.
  > 
  > I think the WG should work on concrete, clear, and 
  > important problems.

=> I guess I don't know how to prove beyond doubt
that the problem is important from a 'market use'
point of view. Perhaps people who suggested these
scenarios have more input on how important they
are, or can motivate others to say that they 
need them.

Hesham

---

From: John Schnizlein <[email-masked]>
Date: Thu, 25 Apr 2002 11:57:43 -0400

Erik,

You probably will have seen the discussion by the time this summary 
reaches you, but it doesn't hurt me to be more succinct. 

My hope is that deciding that support for walled-garden designs were
non-goals of PANA would remove the "requirement" for the enforcement
point to be at an edge other than the one near the point of access,
which is where I would expect the authenticator to be located.

Although this would not necessarily preclude the separation between
the EP and Authenticator, it would remove the only reason I have seen
for this separation. While I worry some about the complexity of this
separation, the potential goal of supporting walled gardens is a
greater worry.

John

At 10:36 AM 4/25/2002, Erik Nordmark wrote:
>John, 
>
>I'm behind on email but I'm trying to understand what
>technical constraint but be created by an edict to not explicitly
>support walled gardens.
>
>   Erik
>
>> One of the technical implications drawn from the 
>> escape-walled-garden model was that the access control would not 
>> be at the edge between subscribers and Internet-like communication, 
>> but instead the edge would be defined between walled gardens. 
>> This "requirement" seems to have re-emerged when the question of
>> locating the EP at the edge was asked explicitly.
>> 
>> Making support for walled gardens a non-goal of the WG (instead
>> of just removing it from the documents reviewed by the IESG)
>> would allow finding other reasons (if they exist) for locating
>> the EP somewhere other than the edge, but would avoid renewing
>> this goal now that the WG has been chartered without it.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 25 Apr 2002 16:03:44 -0700

> I think the WG should work on concrete, clear, and important problems.

There are few issues with this scenario. One is that it is not fully cooked
yet. It's still missing non-PANA related details, such as user interface
(how
to notify user what is happening, when to start and stop the authenticated/
authorized session). The other is, the current feedback we received doesn't
indicate a need for this scenario.

Even if we had decided to handle this case, I believe the current scope of
PANA
would allow this to work. We don't have to place the PAA somewhere deeper
in the network to detect that a PaC is attempting to go beyond a certain
topology.
A PAA located at the edge of the network can very well detect this by
examining
the destination of the packets sent by the PaC.

For the above reasons, I don't think we need to extend the current scope of
PANA
for this scenario.

alper

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 29 Apr 2002 11:30:50 +0200

Alper, 

I agree with your approach below.

Hesham

  >   > -----Original Message-----
  >   > From: Alper E. YEGIN [mailto:[email-masked]]
  >   > Sent: Wednesday, April 24, 2002 5:29 PM
  >   > To: James Kempf; Yoshihiro Ohba
  >   > Cc: Erik Nordmark; Hesham Soliman (ERA); Pana (E-mail)
  >   > Per minimum scope, PANA still leaves the possibility
  >   > that PAA can be separated from EP, but PANA doesn't
  >   > suggest or take extra actions to enable this feature. 
  >   > This separation can be done for some advanced features or 
  >   > optimizations, which are not what PANA is aiming to provide.
  >   > 
  >   > If we have this scenario in the draft, we should clearly state
  >   > that the additional transport and the possible security issues
  >   > of this separation is outside the scope of PANA. And for that
  >   > matter, I don't think this is a good/typical scenario 
  > to list in the
  >   > draft. This is not the fundamental problem PANA is aiming
  >   > to solve.
  >   > 
  >   > I think it is sufficient to see that PANA doesn't prevent 
  >   > this scenario, 
  >   > for those who are interested in using PANA in such an 
  > architecure.
  >   > 
  >   > The usage scenarios and the requirements draft will have to be 
  >   > updated based on the re-defined charter anyways..
  >   > 
  >   > 
  >   > alper
  >   > 
  >   > 
  >   > 
  >   > > Sorry, Yoshi, but if this is considered in scope, then I 
  >   > believe it is
  >   > > incumbent on the working group to explore the 
  > implications of this
  >   > > radical change in the NAS architecture, including 
  >   > security. I would
  >   > > prefer if the WG focused on the simple task first, and 
  >   > that this was
  >   > > excised from the scenarios draft.
  >   > > 
  >   > >             jak
  >   > > 
  >   > > To: "Alper E. YEGIN" <[email-masked]>
  >   > > Cc: "Erik Nordmark" <[email-masked]>; "Hesham 
  >   > Soliman (ERA)"
  >   > > <[email-masked]>; 
  > <[email-masked]>
  >   > > Sent: Tuesday, April 23, 2002 4:38 PM
  >   > > > I agree on the revised scope as long as it still leaves 
  >   > possibilities
  >   > > > anyway for locating PAA one hop away from the PaC and 
  >   > separating PAA
  >   > > > from EP within the same link as PaC.  Although
  >   > > > those two things are not the main focus in the 
  > revised scope,
  >   > > > I personally think that they are worth being 
  > described in the
  >   > > > usage scenario draft for the following reasons:
  >   > > >
  >   > > > Locating PAA one hop away from the PaC might be useful for
  >   > > > 3GPP/802.11 interworking scenario based on the recent 
  >   > comment from
  >   > > > Lionel Morand.  Separating PAA from EP within the same 
  >   > link as PaC
  >   > > > might be useful for load sharing among multiple 
  > access routers
  >   > > > from the viewpoint of implementation cost of the 
  > access routers.
  >   > > >
  >   > > > Yoshihiro Ohba
  >   > > >
  >   > > >
  >   > > > On Tue, Apr 23, 2002 at 03:25:33PM -0700, Alper E. 
  > YEGIN wrote:
  >   > > > >
  >   > > > >
  >   > > > > link as PaC, if we still need to separate PAA from 
  >   > EP, this is still
  >   > > OK,

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 30 Apr 2002 13:52:52 +0200

> Hasham,
  > you quoted my email and you use the M-word. Just to make 
  > sure; I didn't
  > refer to the Market. 
  > 
  > There has to be a clear technical motivation
  > for the use of what we build. Thus if folks can accomplish 
  > 80, 90, or 95% of
  > what they need using existing tools (aka protocols) they 
  > are likely to use
  > those even if the IETF specifies one that is a bit better.

=> oops, I thought you meant to ask whether operators
would be interested in deploying this scenario. That's
why I used the M-word. Sorry if I misquoted you.

Hesham