Subject: Re: Inactive EP detection (was Re: [Pana] PAA-2-EP protocol requirements)

From: [email-masked]
Date: Tue, 2 Dec 2003 14:12:12 -0800

Assume that:

- PAA performs SNMP-based polling to detect inactive EPs at every 60
seconds.
   Say the last polling occured at time T.

- Some EP rebooted after T.  The reboot procedure completes before T+60.

- At the next polling time, PAA will receives response from the rebooted
EP.
  Unless there is some reboot detection mechanism, PAA will not realize
that
  the EP has been rebooted, and as a result states will not be synchronized
between EP and PAA.

I thought that PAA should get reboot counter from EP and check it in
polling procedure, and
this could be used for both inactive peer detection and reboot detection
mechanisms.
I've checked RFC3411 and there is snmpEngineBoot MIB that can be used as
the reboot counter.

On the other hand, it is also possible that EP can send SNMP trap to notify
PAA after rebooting.
This could be used for reboot detection mechanism (in passive manner) but
not for inactive peer
detection mechanism.

Yoshihiro Ohba

   hi Yoshi:

   [email-masked] a écrit:
   >    > a) Inactive peer detection:
   >    > The protocol used between PAA and EP should be able to detect
   inactive
   >    > peer within an appropriate time period. This can be achieved by
   having
   >    > both the EP and remote PAA constantly verify their connection to
   each
   >    > other via keep-alive messages: a heartbeat in fact.
   >
   >    I'm not sure how much "explicit support" we need for this from the
   >    PAA2EP
   >    protocol. There can always be ad-hoc solutions to this. For
   example,
   >    running
   >    some request-reply messages between the PAA and EP can be used as a
   >    keep-alive. I can imagine an implementation resorting to such
   techniques
   >    when the protocol does not have a dedicated facility....
   >
   >
   > Yes, some SMNP implementation can support small value (order of
   seconds)
   > for
   > miminum polling inverval.  This would be sufficient for inactive peer
   > detection, but
   > not sufficient for detecting _rebooted_ peer when rebooting can
   complete
   > within
   > SNMP polling interval. Rebooting detection is needed when EP store
   > PaC information (including accounting information) in volatile memory.
   >
   > So we might need to define some rebooting counters in SNMP MIB in
   order to
   > detect
   > rebooting peers, or if such a MIB already exists we might just specify
   the
   > use of
   > the MIB for both inactive/rebooted peer detection.

   I'm not sure to rightly understand what you mean here, please can you
   elaborate ?

   thanks in advance,
   Yacine

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

---

From: [email-masked]
Date: Thu, 04 Dec 2003 19:13:59 +0100

thanks yoshi, I much better understand the problem now. please see below 
some comments inline:

[email-masked] wrote:

>   the EP has been rebooted, 

since the EP is empty after rebooting, the first packet coming from any 
of the PaC will be considered as unauthorized and trigger a "New PaC 
notification" (PANA auth request message, SNMP trap, or whatever...) to 
the PAA. hence, it is sufficient fot the PAA to be rapidly aware of the 
problem.

> and as a result states will not be synchronized
> between EP and PAA.

in a recent discussion on the stateful/stateless appoach, we (mostly 
alper) agreed that the PAA does not maintain any EP state --> no 
synchronisation anyway.

I would say: once the PAA is aware the EP has rebooted, it should send 
again the set of rules to this EP, based on the PaC states, which are 
maintained in the PAA.

thanks,
yacine

---

From: [email-masked]
Date: Thu, 04 Dec 2003 19:13:59 +0100

thanks,
yacine

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 04 Dec 2003 11:04:21 -0800

> the PAA. hence, it is sufficient fot the PAA to be rapidly aware of the 

But the "new PaC notification" is used only when the PAA is the
initiator of the PANA authentication.  PAA might not able to rely on
the "new PaC notification" from EP if the authentication policy of the
access network allows PaC-initiated PANA authentication only.

> alper) agreed that the PAA does not maintain any EP state --> no 

My understanding is a bit differnet.  PAA needs to mainmain EP state
anyway, but the exact method for maintaining EP state is left to
implementations and does not need to be standardized in the PANA WG
(but I think it would be helpful if we could have some implementation
guidance about the method).

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 04 Dec 2003 11:04:21 -0800

Yoshihiro Ohba

---

From: [email-masked]
Date: Fri, 05 Dec 2003 14:25:32 +0100

> access network allows PaC-initiated PANA authentication only.

I cant see any reason for preventing this notif since it can be useful
for detecting such an EP has rebooted. it doesnt mean that the PAA
initiates a PANA auth at all, it only re-configure the EP with the set
of rules it lost during the reboot.

anyway your MIB object (reboot counter, etc.) could work either...

> guidance about the method).

keeping an EP state in the PAA means the PAA knows what's the current EP
configuration without polling the EP. so far, it's impossible because we
said the EP can be managed by another PAA.

the PAA keeps the PaC state and configure the EPs accordingly, it can
re-configure the EPs, is needed and based on the PaC state it keeps.
that may be what you mean by implementation concern. do you agree ?

finally: for sure, nothing will be standardized in the PANA WG since we
will reuse existing stuff. the only thing here is to determine weither a
stateful approach is needed. for now, it seems not to be the case and I
would like to avoid misunderstandings.

> Yoshihiro Ohba

thank you,
yacine

---

From: [email-masked]
Date: Fri, 05 Dec 2003 14:25:32 +0100

thank you,
yacine

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Dec 2003 09:07:41 -0800

> of rules it lost during the reboot.

There is some problem with using "new PaC notification" for rebooted
EP detection.  The rebooted EP cannot generate the notification until
it sees some packet originated by the PaC.  

> that may be what you mean by implementation concern. do you agree ?

Yes.

> would like to avoid misunderstandings.

I believe that stateful approach is needed in total solution (i.e.,
PAA-EP protocol plus application that runs on top of the PAA-EP
protocol).  But this does not mean PAA-EP protocol itself needs to be
stateful.  If the application can maintain statefulness on top of
stateless PAA-EP protocol by using application-level polling, etc.,
that is fine.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Dec 2003 09:07:41 -0800

Yes.

Yoshihiro Ohba