Subject: PAA-EP protocol requirements

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 28 Oct 2002 12:17:18 -0800

Hello,

In addition to the PANA protocol requirements,
we should also be looking at the PAA-EP protocol
requirements. Since we have decided to enable separation
of the authentication agent from the enforcement points,
we need to (preferably) identify an existing protocol
for the required communication between these entities.

We can add these requirements to the PANA requirements
draft, although we should clearly state these are not
meant for the protocol between PaC and PAA.

Here are few points we should cover:
- PAA should be able to notify an EP for allowing/disallowing
  access for a particular client. This should happen without 
  EP sending a request to the PAA, therefore effectively 
  using a "push model".

- A PAA might be serving a network with multiple EPs. 
  Therefore, protocol should allow PAA to inform multiple
  EPs once a client is authenticated and authorized for
  network access.

- ...

Comments? More requirements?

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 28 Oct 2002 16:17:02 -0500

Three comments.

First, it would be better for the requirement draft to include the
definition of EP which is described in the usage scenarios draft.

Second, I agree that push model (pusing information from PAA to EP)
should be used for the communication between PAA and EP.  On the other
hand, it might be good to have an explicit statement on optional usage
of event notification in the push model in which EP MAY inform PAA
when a new device is connnected to the network, which was discussed
recently on the mailing list and no one seemed to have objected to it.

Third, the protocol used between PAA and EP should be able to detect
inactive peer within an appropriate time period and delete the related
states.  (Then what is the required time scale for detecting inactive
peer?)

Regards,
Yoshihiro Ohba

---

From: "fan zhao" <[email-masked]>
Date: Mon, 28 Oct 2002 18:46:30 -0800

Hello.

One more requirement about PAA-EP protocol:
The PAA MUST have a secure and efficient way to get the accounting
information
of PaC from EP since PAA can be a client of the AAA infrastructure.
By the way, PANA requirement should take into consideration how EP
accounts the usage of PaC securely. (anti-spoofing)

fan

-----Original Message-----
From: Alper E. YEGIN [mailto:[email-masked]]
Sent: 2002?10?28? 12:17
To: Pana (E-mail)
Subject: PAA-EP protocol requirements

Hello,

- ...

alper

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 29 Oct 2002 14:05:15 +0100

>   EP sending a request to the PAA, therefore effectively 

maybe it could be better to write: "for a particular Device Identifier".

>   EPs once a client is authenticated and authorized for

agree

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 29 Oct 2002 11:30:33 -0800

> recently on the mailing list and no one seemed to have objected to it.

I presume this event notification is not part of PANA.
Would it be a part of the PAA-EP protocol, or some out-of-band
optimization, such as a link-layer trigger?

> states.  (Then what is the required time scale for detecting inactive

Master state would be maintained by the PAA. If PaC explicitely signs off,
or times out, then PAA can inform EP about this. Or, are you talking
about EP detecting departure of the PaC and informing the PAA about this?
(which is like the event notification in the previous bullet).

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 29 Oct 2002 15:09:57 -0500

> optimization, such as a link-layer trigger?

I mean event notification as a part of the PAA-EP protocol.

> (which is like the event notification in the previous bullet).

Peer is not a PaC in the above context.  PAA and EP are peers in the
above context.  If PAA detects that EP is not up and running, it
should delete the related states maintained for the EP.  If EP detects
that PAA is not up and running, it should delete the related states
maintained for the PAA.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 29 Oct 2002 13:20:50 -0800

> I mean event notification as a part of the PAA-EP protocol.

If this is an event notification that is meant to signal arrival
of a client to the PAA, and therefore trigger a PANA exchange
initiated by the PAA, then IMO this should not be part of PAA-EP
protocol. This can be seen as an optimization, that can be provided
by some other methods (e.g., link-layer triggers).

Btw, when I go over the past discussion, what I gather is not really
something I described above. That discussion is about EP pulling some
state from PAA (not EP suggesting PAA to initiate PANA with a PaC).

> that PAA is not up and running, it should delete the related states

Yes, probably a timeout mechanism would help there..

alper

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 29 Oct 2002 16:12:26 -0800 (PST)

> state from PAA (not EP suggesting PAA to initiate

yes, there is some confusion regarding what is to be
done when an EP crahes is then come up. Notification
followed by (possibly a new authentication with PACs)
and a push, or a pull.

Regarding notifications and everything, if there is a
protocol running between PAA and EP and the EP
crashed, the PAA would know that and it will know when
the EP comes up since it will try to establish a
connection to the PAA. If it's a new connection then
the PAA can then just send all state to the EP
(similar to BGP, for instance).

On the other hand, the EP will detect that the
connection with PAA went down and will delete all
state (as suggested). When the PAA comes up it will
try to establish a connection with the appropriate
EP(s) and then will start dumping all necessary state
to them.

so, if there is awareness of a connection state in the
application level and we have a keepalive and/or use a
reliable transport protocol (similar to routing
protocols), all detection and synching of state will
come for free.

Before someone jumps on my neck, no I'm not advocating
a routing protocol to do this, I'm just poiting out
that the paradigm is the same

I mean, if you abstract the PANA words, what we want
is to solve a old problem of synching two databases
where one is (possibly?) primary (PAA's). Is this a
fair assessment? 

So all we need is some keep alive above IP, some
sequence numbers to make sure both entities have the
same version of the database and a way to transfer
information securely.

I think this will take of the following situations

1 - PAA crashes and come up
2 - EP crashes and come up
3 - Both crashe and come up.

anyway, that's my take, maybe I'm missing something.

regards,

Reinaldo

> > > Master state would be maintained by the PAA. If
> PaC explicitely signs
> off,
> > > about EP detecting departure of the PaC and
> informing the PAA about
> this?

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 29 Oct 2002 19:19:48 -0500

> by some other methods (e.g., link-layer triggers).

I'm not sure whether link-layer triggers at PAA can cover all the
scenarios.

Consider the following case:

A PAA and an EP are seperated and connected to a subnet via an
Ethernet switch (not a hub), the PAA may not see data packets sent
from a PaC at all.  Then how the PAA can initiate PANA authentication
without allowing the EP to inform PAA when the EP captures data
packets sent from a new device?

Yoshihiro Ohba

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 29 Oct 2002 17:10:03 -0800 (PST)

Hello Yoshi, 

Isn't this a discovery problem? why try to fix it at
the EP<->PAA communication?

Shouldn't the PAC discover the PAA or the EP send some
ICMP or whatever back to the PAC so that he tries to
contact the PAA?

regards,

Reinaldo

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 29 Oct 2002 21:10:24 -0500

> the EP<->PAA communication?

No, it is not a part of a discovery problem, since the discovery is
used for PaC to discover the PAA.

> ICMP or whatever back to the PAC so that he tries to

Both two cases just cover PANA authentication initiated by PaC.  ICMP
is just a trigger for PANA authentication initiated by PaC, I think.

What I'm mentioning here is about a trigger for PANA authentication
initiated by PAA.

Yoshihiro Ohba

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 29 Oct 2002 19:26:33 -0800 (PST)

I saw your point, but I think I didn't convey my
question right...

the more basic question is: should we provide for this
case where the EP notifies the PAA explicitly in the
PAA<->EP protocol? If yes, do we still need discovery?

Should we assume that the PAC will always be able to
discover who the PAA is, so in a sense most of the
time (except when PAA and EP are co-located) the PAC
is the one initiating authentication?

If this is not the case, do we still need discovery,
given the models listed in the requiremetns draft?
Looking at those models it seems to me all packets
reach an EP first, which can always ask the PAA to
initiate authentication?

any thoughts?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 30 Oct 2002 10:29:24 -0500

I think it might be useful to view authentication 
from the following two aspects:

o Which is the initiator of authentication, client initiated or
  authenticator initiated?

o What is the trigger, traffic driven or connectivity driven, or other?
  (In the case of traffic driven trigger, authentication is triggered
   when data traffic is generated at a particular layer. In the csae
   connectivity driven trigger, authentication is triggered when
   connectivity is established at a particular layer.)

I think those two aspects are orthogonal, thus there are at least 4
combinations.

For example, 802.1X is classified as client initiated, L2 connectivity
driven authentication.  Web-based authentication is classified as
authenticator initiated, L4 traffic driven authentication.  At least
these two combinations (client-connectivity and authenticator-traffic)
need to be supported in PANA to give flexibility in authentication for
different usage scenarios, and it would be better to support all
combinations to give maximum flexibility, IMHO.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 30 Oct 2002 19:06:15 -0800

> PAA<->EP protocol? 

Either that, or the EP can inform PAC that it has to
use PANA first (e.g., by sending an appropriate
ICMP unreachable message).

> If yes, do we still need discovery?

Yes. Because, if a client knows it has to use PANA
on a given access network, it can immediately start
with PAA discovery, rather than attempting to send
a data packet which will go nowhere.

> is the one initiating authentication?

Even though PaC can start with PAA discovery, it might
behave "optimistically" and skip that, just send its
data packets. So, we can assume PaC will always be
able to discover, but it doesn't always have to do that.

> reach an EP first, which can always ask the PAA to

I think we still need discovery, see above..

alper