Subject: RE: [Pana] Issue 114: Clarify liveness test

From: [email-masked]
Date: Fri, 17 Dec 2004 14:02:24 +0200

Hi,

In PANA scope there is a possibility for state synchronization problem
with this approach (serious interoperability problem).

This states clearly when the session expires:

 "Therefore, at the latest a disconnected client can be detected when
 its session expires."

But this implicitly makes this session expiration fuzzy:

 "This test can be engaged when there is a possibility that the peer
 might have disconnected (e.g., after the discontinuation of data
 traffic for an extended period of time).

What happens if there is no PANA-Ping-Answer message? First, we have
not specified how many times the retransmission will happen.. so how
long the sender of the PANA-Ping-Request message should wait? What if
the wait time is too short (i.e. the other peer assumes longer wait
time than the other peer really implements)?

The problem is that PaC and PAA as a result may have different
understanding of the session state.

For solving this interoperability problem there are two choices:

(a) Remove PANA-Ping message pairs and all text about liveness test.

(b) Clearly define what happens if the liveness test fails in the
    context of PANA session AND specify the wait times. Anything else?

I would go with the choice (a) and put the choice (b) into the
mobility optimization working document sometime in the future.

Br,
- Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Alper Yegin
> Sent: 16 December, 2004 00:11
> To: [email-masked]
> Subject: [Pana] Issue 114: Clarify liveness test
> 
> 
> http://danforsberg.info:8080/pana-issues/issue114
> 
> Let's add a clause to 11.8 about the liveness test side-effect of any 
> valid request/answer exchange.
> 
> On top of that, I did some editorial by breaking the one big 
> paragraph 
> into smaller ones. It seems like we have been a bit on the 
> stingy side 
> with using paragraphs ;-) 
> 
> 
> New text for section 11.8 (from version 7a):
> 
> 11.8  Livenes Test
> 
>    A PANA session is associated with a session lifetime.  The 
> session is
>    terminated unless it is refreshed by a new round of EAP
>    authentication before it expires.  Therefore, at the latest a
>    disconnected client can be detected when its session expires.  A
>    disconnect may also be detected earlier by using PANA ping 
> messages.
>    A request message can be generated by either PaC or PAA at any time
>    and the peer must respond with an answer message.  A successful
>    round-trip of this exchange is a simple verification that 
> the peer is
>    alive.  
> 
>    This test can be engaged when there is a possibility that the
>    peer might have disconnected (e.g., after the 
> discontinuation of data
>    traffic for an extended period of time).  Periodic use of this
>    exchange as a keep-alive requires additional care as it 
> might result
>    in congestion and hence false alarms.  
>    
>    This exchange is cryptographically protected when a PANA SA is 
>    available in order to prevent threats associated with the abuse 
>    of this functionality.
> 
>    Any valid PANA answer message received in response to a recently 
>    sent request message can be taken as an indication of peer's
>    liveness. PaC or PAA MAY forgo sending an explicit 
> PANA-Ping-Request
>    if a recent exchange has already confirmed that the peer is alive.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana
> 

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Dec 2004 02:51:00 -0500

Hi Dan,

> time than the other peer really implements)?

I agree on your observation.  This is a problem.

As far as I understand, the cause of this problem is that requests
(including PPR) follow the retransmission rule described in
"Transmission and Retransmission Parameter" but the rule just defines
the default values for the retransmission parameters.  As a result,
PaC and PAA implementations can diverge to take arbitrary values for
those parameters.

If we can specify the maximum values for the retransmission parameters
(e.g., defining the maximum value for "Max Request timeout value"), I
think we can deal with the out-of-synch problem to some extent.

> (a) Remove PANA-Ping message pairs and all text about liveness test.

Liveness test is an important functionality of PANA and the
functionality should be defined in the base specification.

> mobility optimization working document sometime in the future.

I think liveness test and mobility optimization are totally separate
features and choice (b) does not make sense to me.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Dec 2004 12:08:27 -0800

> > long the sender of the PANA-Ping-Request message should wait? 

As Yoshi pointed out, PPR is governed by the same retransmission
behavior as any other request as described in Section 9.

> > What if
> > the wait time is too short 

This is a deployment/architecture issue. Each deployment should decide
based on its environment. We cannot possibly know any of these
here...... 

It's not at all that surprising if an operator misconfigures the system
and system does not work properly. 

> > (i.e. the other peer assumes longer wait

Well, if a peer receives a request, it does not "assume" how long the
sender is willing to wait and sit on the answer. It must transmit the
answer as soon as it can.

> PaC and PAA implementations can diverge to take arbitrary values for

Of course... That's what an architecture can help with. If I'm using
PANA in 3GPP2, I'd recommend some values that are suitable to a cdma2000
network (default, max values, etc.). 

> think we can deal with the out-of-synch problem to some extent.

We already have that. Please see MRC, MRT, and MRD values.

I agree with Yoshi on his two points below.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Dec 2004 05:48:38 -0500

Hi Alper,

I have one comment.

> We already have that. Please see MRC, MRT, and MRD values.

But those maximum values are configurable *variables" and there is no
*constant* upper-limit for those maximum values.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 17 Dec 2004 15:44:45 -0800

> *constant* upper-limit for those maximum values.

How can there be? Do you want to prevent people using PANA in
super-high-latency inter-galactic networks? ;-) 

Even if we had a limit on that, I cannot understand how this helps.
Still it is a configurable parameter and an impatient PAA may blow away
PaC's session sooner than such a MAX timeout.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Dec 2004 08:26:08 -0500

> super-high-latency inter-galactic networks? ;-) 

I don't know how large the latency in such networks is.. :)

> PaC's session sooner than such a MAX timeout.

I'd say that state synchronization loss period can be bound to the
extent determined by the upper-limits for those maximum values.  If
the upper-limits are too large it won't help.  I don't have a strong
opinion on having upper-limits for those maximum values.
	
Yoshihiro Ohba