Subject: RE: Issue 8

From: <[email-masked]>
Date: Thu, 26 Jun 2003 11:08:47 +0300

Alper,

> >>>> Network does not have to inform the PaC about the grace
> >>>> period. It does not
> >>>> even have to have a grace period. It's just a courtesy to
> >>>> have one. Do you
> >>>> have examples of other similar protocols carrying grace
> >>>> period in addition
> >>>> to authorized lifetime to their clients?
> >>> 
> >>> Session-Lifetime, Auth-Grace-Period, and
> >> Authorization-Lifetime AVPs are all
> >>> used in the Diameter base protocol. The AAA home server
> >> decides the lifetimes.
> >> 
> >> Are they transmitted to the peer in 802.1X, PPP, or Mobile
> >> IPv4? That's my
> >> question. I'm trying to understand what should be carried in
> >> PANA. Your
> >> above example is about what gets carried in backend AAA protocol.
> > 
> > EAP goes through the AAA backend, which uses grace period.
> > If PANA now thinks that for example one second is enough
> > to start re-auth before session timeout, it in practice may
> > not be enough (network lag, packet loss, clock difference).
> > Since AAA backend uses grace period and assumes that re-auth
> > is received in that period, it tears down the session when
> > timeout occurs.
> 
> This doesn't really answer my question. As far as I know, 
> these protocols
> would transmit (at most) one timer to the client (peer, MN, 
> etc), that's the
> granted session lifetime.

See my comments about grace period below.

> 
> >> It's really up to PAA. If PAA wants to enable this, it can
> >> send frequent
> >> enough reauths to detect PaC's departure. No need to negotiate.
> > 
> > The link between PaC and PAA may go down or/and packets may get
> > lost. If there is no negotiation about the refresh period, but
> > PAA is doing perioidic re-auths, the states in PaC and PAA may
> > become different. PaC thinks that the session is still alive, but
> > the PAA has torn it down, because there was no answer from PaC to
> > the re-auth request. Don't you think this is serious enough?
> 
> If there is such a condition where PaC cannot respond to re-auth
> (connectivity problem), this condition will of course result 
> in PaC getting
> kicked out of the network. The PaC knowing when it will be 
> asked to reauth
> is not going to help. So, again, I don't see the need to negotiate the
> reauth timers.

PaC is kicked out by the network, but PaC may not know about it! Even 
if the L2 looses link at some points (L2 triggers) which causes packet 
loss from PAA to PaC (re-auth) it doesn't mean that PaC thinks it has 
been kicked off, because it doesn't know about the refresh period. 

This is a flaw in the design and we need to resolve it.

> 
> What we really need to do is to put lots of warnings in the 
> spec saying that
> false alarms might cause disconnection of live clients. This 
> is what we
> discussed earlier regarding keep-alives. If PAA is going to use reauth
> message as a keep-alive mechanism, it must be very careful.

We have to think about PaC's viewpoint too. Anyway, even how many 
warnings we add to the spec, the scenario doesn't work.

> 
> >> As I have said, limiting this does not prevent DoS. There are
> >> other ways to
> >> achive the same DoS. I presume you don't have an example of
> >> protocols that
> >> set lower limits (or, did I miss it?)
> > 
> > Nothing comes to my mind now, because the network usually makes
> > the final decision. Do you have examples of relevant protocols
> > that let the client make the final decision for lifetime or refresh
> > period (without letting the other end know about it)?
> 
> Lets not confuse when reauths are sent with PANA session 
> lifetime. Latter is
> handled the way you describe. PAA rules. We are talking about 
> when reauth
> can be sent, which can be left to PAA and PaC.
> 
> [for clarification: PANA session lifetime is granted by the 
> PAA (or, AAA
> backend). PaC must to perform full EAP exchange (PANA-auth) 
> before current
> PANA session lifetime expires. Within this lifetime, PaC and PAA may
> initiate PANA-reauth whenever they wish to.]
> 
> IMO, Re-auth is not the same as the full authentication. It 
> does not have to
> have all the features of full authentication. It enables the peers to
> perform a quick test without having to do full 
> authentication. We should not
> even assume it will always be used periodically. For example, 
> it can be
> engaged when the peer has a suspicion (hints needed here) 
> that the other end
> is gone/compromised/etc....

The advantage of re-auth is that full AAA backend involved auth is 
not needed. If IPSec is in use, re-auth may not be necessary at 
all. Refresh interval negotiation is needed if refreshes are used.

> 
> >> OK, at least you don't have objection to the way session 
> lifetime is
> >> handled. 
> > 
> > Yep. But some kind of co-operation is needed here when AAA backend
> > Session-Timeout is used (see explanation above). 
> Grace-period is there
> > already, which makes it a natural choice to use (optional 
> AVP perhaps)?
> > 
> > PAA could decrease the Session-Timeout value with the 
> amount of grace
> > period and PaC could start re-auth (full) after 
> Session-Timeout? In this
> > case PaC doesn't know how long the session will still remaain valid,
> > because it doesn't know the grace period.
> 
> I don't quite understand how you use the grace period. To me, 
> it should be
> used like this:
> - PAA and PaC agrees on the session lifetime. PaC must initiate full
> authentication before this session lifetime expires.

Ok. The term is Session-Timeout in Diameter spec. It may be more 
descriptive about the nature of the timer. 

> - PAA might grant a grace period. Grace period is the extension of the
> sesion lifetime during which PaC is allowed to get 
> authenticated. So, on the
> PAA side, the effective allowed lifetime is 
> session_lifetime+grace_period.
> But, on the PaC, it is session_lifetime and PaC think it has 
> to do PANA
> before this period expires.

The formula once again is (based on the Diameter spec.)

  authorization_lifetime + grace_period <= session_timeout

If PAA sends Session-Timeout for PaC, we may get into trouble. 
But if PAA sends (Session-Timeout - Grace-Period) for PaC, we 
are more safe. I still think that sending both Session-Timeout 
and Auth-Grace-Period AVPs is a better solution.

Grace period doesn't add anything to the session lifetime. I guess 
it's a hint from the network for the client to start (full) re-auth
*early* enough (implemenations need timners anyway).

> 
> So, the grace period delivered by AAA must be for the 
> consumption of PAA(or
> NAS, or AP). Is that not the case?

I guess I don't understand the question. There is no PaCs or 
MNs in AAA, but AAA clients that are not mobile (NAS, AP, PAA).

Summa summarum. I propose that PAA sends Session-Timeout and 
Auth-Grace-Period AVPs for PaC. For the refresh interval issue, 
I propose that if refreshes are used PAA informs PaC about the
limits of possible refresh intervals (upper and lower). AVP used
for this could be for example Refresh-Interval-Limits and the 
data would contain two 16 bit unsigned integer values for lower 
and upper limits in seconds.

Any comments?

Br,
- Dan

> Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 26 Jun 2003 09:23:48 -0700

Hi Dan,

Please see my comments in line.

> This is a flaw in the design and we need to resolve it.

I cannot find a requirement in the PANA requirements draft on PaC and
PAA to be synchronized on interval for performing refresh or
peer-unreachability detection.  So I don't think it a design flaw.  

If we take a look at other protocol, for example IKEv2, it supports
peer-unreachability detection but the initiator and responder does not
exchange any interval on it (and I don't find a problem in such a
design).

> and upper limits in seconds.

I think it might be better to study more about other protocols.

For example, IEEE 802.1X does not carry an authorization-timeout
interval or a grace period.  This is because re-authentication due to
expiring authorization lifetime is always initiated by the IEEE 802.1X
authenticator who knows (through RADIUS/Diameter attributes) when the
authorization lifetime expires and what the grace period is.  In
addition, IEEE 802.1X supplicant can also initiate re-authentication
anytime by just initializing its state.

IKEv2 is similar to IEEE 802.1X in state management policy, i.e., no
interval is negotiated for peer-unreachablity detection or even for SA
lifetime.  The initiator and responder independently performs
peer-unreachablity detection and re-negotiation of SAs whenever
needed.

In the case of Mobile IP or Mobile IPv6, registration or binding
lifetime is negotiated.  This is because registration or binding
update is always initiated by the mobile node (except for MIPv6
Binding Refresh Request sent by a correspondent node but the purpose
seems to be a bit different).  On the other hand, a grace period is
not negotiated because (I think) the time to complete registration or
binding update is predictable.

In my opinion, we can design PANA without carrying Session-Timeout or
Auth-Grace-Period AVPs, as IEEE 802.1X and IKEv2 are designed so.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 26 Jun 2003 13:18:41 -0700

Yoshi,

> Auth-Grace-Period AVPs, as IEEE 802.1X and IKEv2 are designed so.

No objection to not carrying Auth-Grace-Period. But, is giving the
responsibility of re-doing PANA to PAA better than distributing it to each
PaC? Are there advantages of doing that? [I understand 802.1X and IKE do one
way, Mobile IP does other way, but each may have its own reasons...]

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 26 Jun 2003 15:33:39 -0700

> way, Mobile IP does other way, but each may have its own reasons...]

One obvious advantage for not carrying any time-related parameter is
simplicity.  In the case of Mobile IP, the lifetime needs to be
carried in signaling message, because the mobile always initiate
registration, and such a design seems to be valid for a mobility
management protocol, because the home agent basically cannot know by
itself when or where a handoff (which will need a binding update)
occurs on the mobile.

Yoshihiro Ohba