Subject: RE: Issue 8

From: <[email-masked]>
Date: Tue, 24 Jun 2003 12:32:02 +0300

Hi Alper,

> >>> - We need a grace period too:
> >>> Authorization-Lifetime + Auth-Grace-Period <= Session-Timeout
> >>> Here
> >>> Auth-Grace-Period < Authorization-Lifetime
> >>> Unit is seconds. Auth-Grace-Period is a configurable parameter
> >>> and delivered from PAA to PaC.
> >> 
> >> I agree there might be a grace period, but I think this 
> can be a local
> >> decision (via implementation, configuration). Does the
> >> protocol have to
> >> carry this information to the other end (PaC)?
> > 
> > Grace period depends on the authorization and session lifetime.
> > Network decides both of these (at least the limits), so PaC
> > must be informed.
> 
> 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.

Auth-Grace-Period is implicitly used in any case, because we have to make a choice when to start re-authentication before the session-lifetime ends. If we nail it down in the spec, it creates limits for the session lifetime and refresh interval. That's ok for me.

> 
> > 
> > I guess we could have many authorization (refresh) periods in one
> > session lifetime. If PaC fails to reauthenticate (PANA refresh) in
> > the given authorization (refresh) period, the session is also torn
> > down.
> > 
> >>> - PaC should propose something and PAA then decides the actual
> >>> refresh period and session lifetime (the network knows better
> >>> the upper and lower limits for re-auth etc.).
> >> 
> >> Now that I'm thinking, maybe we should only pass the 
> Session-lifetime
> >> between PAA and PaC, and not worry about Reauth-lifetime. PaC
> >> and PAA don't
> >> need to share the Reauth-lifetime, each can trigger reauth as
> >> often as they
> >> like/need. But for Session-lifetime, PaC should know it so 
> that it can
> >> perform PANA authentication again before its session 
> expires and PAA
> >> disables network access.
> > 
> > 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? In MIPv6 for example the HA sends optionally a Binding Refresh Advice for the MN (draft23, sec. 6.2.4).

If we let PaC and PAA initiate refresh any time, the refresh message becomes a legitimitate DoS attack (PaC or PAA floods refresh messages). If we have a negotiated refresh period, PAA/PaC doesn't have to process refresh messages all the time, but can discard them (defense). 

Time based accounting benefits from negotiated refresh period. 

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

> 
> > Protocol should be
> > clear about this.
> 
> Is this not clear (this is in the pana-00 draft):
> 
>    The second type of re-authentication is based on a single protected
>    message exchange without entering the authentication phase.
>    PANA_reauth/PANA_reauth_ack messages are used for this purpose.  If
>    there is an established PANA SA, both PaC and PAA can send a
>    PANA_reauth message to the communicating peer whenever it needs to
>    make sure the availability of the PANA SA on the peer and 
> expect the
>    peer to return a PANA_reauth_ack message.  Both PANA_reauth /
>    PANA_reauth_ack messages MUST be protected with a MAC AVP.
> 
> > Otherwise both PaC and PAA might try to do it at the
> > same time. 
> 
> Is this a problem? If PaC receives a PANA-reauth-request 
> before it sends
> its own, it can reset its timer (or, optionally keep its own 
> timer and stick
> to its schedule regarding sending PANA-reauth-requests). Even if two
> PANA-reauth-requests cross each other, this cannot be a 
> problem either, as
> each peers would respond to them.

See comments above.

> 
> > Not clear enough for a protocol spec.
> > 
> > One way to go is to let PaC initiate the re-authentication after the
> > authorization lifetime has been exceeded and grace period 
> starts. Grace
> > period is needed for the processing the refresh/reauth 
> (only the network
> > knows how much time a refresh can take).
> > 
> >> 
> >> 
> >>> PaC can optionally
> >>> propose a Authorization-Lifetime to PAA within a PANA-Auth-Request
> >>> message. 
> >> 
> >> I also thought about first PaC requesting a value and PAA
> >> granting one. But
> >> then looking at the message flows, the other direction seems
> >> to better fit
> >> the current design. Instead of one of the PANA-auth messages
> >> carrying this
> >> info from PaC to PAA, and the response coming back in
> >> PANA-success, I think
> >> doing it symmetrically in PANA-success/ack is better. PANA
> >> module on the PaC
> >> won't really know in which PANA-auth message this AVP should
> >> be included.
> > 
> > Yes, this is a problem. If PaC makes the final decision, then
> > the network should inform both the lower and upper limits. We may
> > need more AVPs?
> 
> In my proposed text, PAA already informs the PaC about the 
> upper limit.
> 
> > 
> >> 
> >>> PAA sends Authorization-Lifetime and Auth-Grace-Period
> >>> AVPs to PaC in PANA-Result-Request message. PAA can also send
> >>> Session-Timeout AVP to denote the total lifetime of the session.
> >> 
> >> I don't think we need to pass the grace-period to the PaC.
> >> (well, if we do,
> >> it is no longer seen as grace period, but as part of 
> granted period :)
> > 
> > Grace period doesn't add to the session lifetime, but to the
> > authorization lifetime.
> > 
> > authorization_lifetime + grace_period <= session_lifetime
> > 
> >> 
> >> 
> >> How about this:
> >> 
> >> - 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.

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

> 
> > 
> >> 
> >> - Both PaC and PAA can initiate re-auth whenever they need to.
> > 
> > This must be clarified in the spec. The proposal for issue8 doesn't
> > take care of this yet.
> 
> Spec already has a text on this.

With clarification I meant the negotiation.

- Dan

> 
> Alper
> 
> 
> 
> > 
> > - Dan
> > 
> >> 
> >> Does this make sense?
> >> 
> >>> 
> >>> - PANA-Reauth-Request from PAA can optionally contain
> >>> Authorization-Lifetime AVP to denote the re-auth interval
> >>> (if network wants to change it)?
> >>> 
> >>> 
> >> 
> >> 
> >> Alper
> >> 
> >>> Br,
> >>> - Dan
> >>> 
> >>> 
> >>>> -----Original Message-----
> >>>> From: ext Alper Yegin [mailto:[email-masked]]
> >>>> Sent: 11 June, 2003 00:10
> >>>> To: [email-masked]
> >>>> Subject: Issue 8
> >>>> 
> >>>> 
> >>>> 
> >>>> http://danforsberg.info:8080/pana-issues/issue8
> >>>> 
> >>>> 
> >>>> How about if we:
> >>>> 
> >>>> - define a refresh (re-auth) lifetime AVP.
> >>>> - PAA MUST include this AVP in the PANA_success to provide
> >> the maximum
> >>>> allowed refresh lifetime for the PANA session.
> >>>> - PAA MAY include this AVP in the PANA_success_ack to lower
> >>>> the required
> >>>> PANA refresh lifetime.
> >>>> 
> >>>> At the end of PANA_success round, both PAA and PaC knows
> >> the refresh
> >>>> frequency. 
> >>>> 
> >>>> PaC MAY send PANA_reauth before this period expires. PAA 
> MUST send
> >>>> PANA-reauth if there was no PANA-reauth exchange for one
> >> full period.
> >>>> 
> >>>> Comments?
> >>>> 
> >>>> Alper
> >>>> 
> >>>> 
> >>> 
> >>> 
> >>> 
> >> 
> >> 
> > 
> > 
> 
>

---

From: Alper Yegin <[email-masked]>
Date: Tue, 24 Jun 2003 19:52:16 -0700

Dan,

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

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

> In 
> MIPv6 for example the HA sends optionally a Binding Refresh Advice for the MN
> (draft23, sec. 6.2.4).
> 
> If we let PaC and PAA initiate refresh any time, the refresh message becomes a
> legitimitate DoS attack (PaC or PAA floods refresh messages). If we have a
> negotiated refresh period, PAA/PaC doesn't have to process refresh messages
> all the time, but can discard them (defense).

If the PaC wants to launch a DoS attack, it does not need re-auth messages.
It can send authenticated data packets or PANA-auth messages. Same level of
DoS can be achieved that way. So, including a reauth timer negotiation to
make re-authentication happen on  a schedule does not help prevent such DoS
threats. 

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

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

...

> 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?)

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

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. 

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.

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