Subject: RE: Issue 8

From: <[email-masked]>
Date: Wed, 25 Jun 2003 10:21:05 +0300

Alper,

Couple of comments once more. I agree that the DoS attack 
scenario is not too important. We have here two issues: 
grace period information and refresh period negotiation.

> >> 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.
 
> >>> Is it PaC's or PAA's responsibility to do reauth?
> >> 
> >> Any can do. It's up to the entity. If PAA believes it 
> needs to perform
> >> re-auth, it can do so. Same for PaC. The signaling can be
> >> initiated from any
> >> direction, and the other end has to respond when it receives
> >> a request.
> >> That's why I don't think PaC and PAA need to coordinate
> >> anything on this.
> > 
> > When does PaC or PAA know when to do reauth if they don't 
> negotiate it?
> 
> This is a local decision. Nothing that requires other peer's 
> collaboration,
> right? 

Collaboration is needed, see below.
 
> > In 
> > MIPv6 for example the HA sends optionally a Binding Refresh 
> Advice for the MN
> > (draft23, sec. 6.2.4).

We could take similar approach in PANA. Refresh period negotiation 
can be optional.

> > Time based accounting benefits from negotiated refresh period.
> > 
> 
> 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?

> > With multihoming (see issue16) refresh messages can be used 
> to refresh
> > different "bindings" in one session. Here negotiated 
> interval is needed.
> > 
> 
> ...

The same logic here than above.

> 
> >>>> - PAA sends (offered) session-lifetime in PANA-success
> >>>> message to the PaC.
> >>>> If PaC wants to lower the session-lifetime, it MAY 
> include a lower
> >>>> session-lifetime in PANA-success-ack.
> >>> 
> >>> We need the lower limit too. I guess this could be stated
> >> in the spec,
> >>> but the scenarios are different and the network may want to
> >> use different
> >>> limits, even dynamically (depending on the signaling load etc.).
> >> 
> >> Why do we need the lower limits? Do other protocols do that?
> > 
> > MIPv6 draft uses "Binding Refresh Advice" (sec. 6.2.4) and 
> also the HA finally
> > makes the decision about the BU lifetime. If I remember 
> correctly in MIPv4 the
> > MN suggests a lifetime but the network makes final 
> decision. There is no need
> > for lower limit "advice", because the network decides.
> > 
> > If we use seconds in the AVP the lower limit is 1s. The 
> network may want to
> > make it higher to prevent signaling flood with many 
> clients. If we make the
> > lower limit to 5s, that may be too high or too low.
> 
> 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)?

> 
> > 
> >> 
> >>> 
> >>>> 
> >>>> - It's the responsibility of PaC to perform PANA before its
> >>>> current session
> >>>> expires. [note: here we are talking about full authentication
> >>>> where an EAP
> >>>> method is executed, not re-auth]
> >>> 
> >>> Yep. We have two authentications: local refresh, and EAP re-auth.
> >> 
> >> No, this is exactly what I'm trying to clarify. What you
> >> refer to as "local
> >> refresh" is done by using PANA-reauuth-req/ans. This should
> >> have nothing to
> >> do with Session-lifetime. PaC and PAA can do this as often as
> >> they need to.
> > 
> > That's right. But PaC and PAA need to co-ordinate the 
> refresh period (see
> > comments above).
> > 
> >> 
> >> On the other hand, PANA-auth (that carries EAP) needs to be
> >> done before
> >> Session lifetime exprires. This is what I'mm talking about in here.
> > 
> > Yep, but the issue8 was all about refresh interval 
> negotiation. Session
> > lifetime negotiation is a different issue. Anyway, it's 
> good that it's solved.
> 
> 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.

> 
> Now we are only talking about reauth timers. I don't see why 
> PaC and PAA
> needs to coordinate when they send their re-auth requests (as 
> I explained
> above). PaC and PAA might have different reasons to send this 
> request. For
> example, PaC might use this to test if it is still connected 
> to the same PAA
> (and not to a malicious PAA). PAA might use this to detect if PaC has
> departed the network (before session lifetime expires). Both 
> sides sending
> the requests independent of each other does not cause 
> problems. As for using
> this coordination for preventing DoS, I don't think this buys you much
> either. 

The problem is that state in PaC and PAA may loose synchronization. 
See the scenario above.

> Since I don't see its utility, for the sake of keeping the 
> protocol simple,
> I vote for not having this negotiation facility built into 
> the protocol.

We need somehow to handle the problem.

- Dan

> But, I clearly see the need to add more text into the draft 
> explaining what
> reauth is (and what it is not). And some guidelines on what 
> it can be used
> for. 
> 
> Alper
>

---

From: Alper Yegin <[email-masked]>
Date: Thu, 26 Jun 2003 00:23:02 -0700

Dan,

> is received in that period, it tears down the session when

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.

...

> 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.

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.

...

> 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....

> 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.
- 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.

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

Alper