Subject: [Pana] Issue 105: Inconsistent and unclear usage of "reauth" messages

From: Alper Yegin <[email-masked]>
Date: Mon, 16 Aug 2004 13:19:27 -0700

Here is an attempt to resolve Issue 105.
The following text changes separate EAP-based reauthentication from
liveness test. The latter is accomplished by PANA-Ping-Request/Answer
now (renamed from PANA-Reauth-Request/Answer).

Comments welcome.

[1] In Section 3:

Change:

   In addition, PANA defines the following two types of
   re-authentication procedures that are performed while an established
   PANA session exists.

   1.  Re-authentication based on EAP

   2.  Re-authentication based on PANA-Reauth exchange

   The former type of re-authentication is used mainly for extending
   authorization lifetime or for updating the cryptographic keying
   material of a PANA SA.  The latter type of re-authentication is used
   mainly for maintaining the presence of the communicating peers each
   other so that the established PANA session can be terminated as soon
   as the presence of the peer is lost.

To:

   In addition, PANA allows re-authenticaiton of the PaC and PAA by
   allowing any one of them to initiate an EAP authentication during
   an on-going PANA session. Refreshing the session and cryptographic
   keys are possible reasons to engage in re-authentication.

   Finally, the protocol enables PAA and PaC ping each other to test 
   liveness of the session. 

[2] In Section 3.1:

Change:

  o  Re-authentication based on the PANA-Reauth-Request/ PANA-Reauth
      exchange is performed.

To:

  o  Liveness test based on the PANA-Ping-Request/PANA-Ping-Answer
      exchange is performed.

Change:

 // Re-authentication based on PANA-Reauth exchange
         <-----     PANA-Reauth-Request[Session-Id, MAC]
         ----->     PANA-Reauth-Answer[Session-Id, MAC]

To:

 // Liveness test based on PANA-Ping exchange
         <-----     PANA-Ping-Request[Session-Id, MAC]
         ----->     PANA-Ping-Answer[Session-Id, MAC]

[3] In Section 4.1.7:

Change:

 *  In discovery and initial handshake phase:

         +  PANA-Termination-Request and PANA-Reauth-Request.

To:

 *  In discovery and initial handshake phase:

         +  PANA-Termination-Request.

Change:

   *  In authentication phase:

         +  PANA-PAA-Discover.

         +  PANA-Termination-Request and PANA-Reauth-Request.

To:

   *  In authentication phase:

         +  PANA-PAA-Discover.

         +  PANA-Termination-Request.

[4] New text for Section 4.4:

4.4  Re-authentication

   An already authenitcation PANA session can enter an authentication 
   phase by re-executing EAP. In this case, some or all message
exchanges
   for discovery and initial handshake phase MAY be omitted in the
   following way.  When a PaC wants to initiate re-authentication, 
   it sends a unicast PANA-PAA-Discovery message to
   the PAA.  This message MUST contain a Session-Id AVP which is used
   for identifying the PANA session on the PAA.  If the PAA already has
   an established PANA session for the PaC with the matching identifier,
   it sends a PANA-Auth-Request message containing the same identifier
   to start an authentication phase.  If the PAA can not recognize the
   session identifier, it proceeds with regular authentication by
   sending back PANA-Start-Request. When the PAA initiates
   re-authentication, it sends a PANA-Auth-Request message containing
   the session identifier for the PaC to enter an authentication phase.
   PAA SHOULD initiate EAP authentication before the current session
   lifetime expires.  In both cases, the tseq and rseq values are
   inherited from the previous (re-)authentication.  For any
   re-authentication, if there is an established PANA SA,
   PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected by
   adding a MAC AVP to each message.  Any subsequent EAP-based
   authentication MUST be performed with the same ISP and NAP that was
   selected during the initial authentication.  An example sequence for
   a re-authentication initiated by a PaC is shown in Figure
   6.

      PaC      PAA  Message
      ------------------------------------------------------
         ----->     PANA-PAA-Discover(0,0)[Session-Id]
         <-----     PANA-Auth-Request(p,q)[Session-Id, EAP, MAC]
         ----->     PANA-Auth-Answer(q+1,p)[Session-Id, EAP, MAC]
         <-----     PANA-Auth-Request(p+1,q+1)[Session-Id, EAP, MAC]
         ----->     PANA-Auth-Answer(q+2,p+1)[Session-Id, EAP, MAC]
         <-----     PANA-Bind-Request(p+2,q+2)
                       [Session-Id, EAP{Success}, Device-Id, Key-Id,
                        Lifetime, Protection-Cap., PPAC, MAC]
         ----->     PANA-Bind-Answer(q+3,p+2)
                       [Session-Id, Device-Id, Key-Id, PPAC, MAC]

  Figure 6: Example Sequence for EAP-based re-authentication initiated
                                 by PaC

[5] Create a new section after the current Section 4.4

4.5. Liveness Test
 
   PANA-Ping-Request and PANA-Ping-Answer messages are used for testing
   the liveness of the PANA session on the PANA peer. If there is an 
   established PANA session, both the PaC and
   the PAA are allowed to send a PANA-Ping-Request message to the
   communicating peer whenever they need to make sure the availability
   of the session on the peer and expect the peer to return a
   PANA-Ping-Answer message.  Both PANA-Ping-Request and
   PANA-Ping-Answer messages MUST be protected with a MAC AVP when a
   PANA SA is available.

   Implementations MUST limit the rate of performing this test.  
   The PaC and the PAA can handle
   rate limitation on their own, they do not have to perform any
   coordination with each other.  There is no negotiation of timers for
   this purpose.

   Figure 7 and Figure 8 illustrate liveness tests as they are initiated
   by the PaC and the PAA respectively.

      PaC      PAA     Message(tseq,rseq)[AVPs]
      ------------------------------------------------------
         ----->        PANA-Ping-Request(q,p)[Session-Id, MAC]
         <-----        PANA-Ping-Answer(p+1,q)[Session-Id, MAC]

        Figure 7: Example Sequence for PaC-initiated liveness test

      PaC      PAA     Message(tseq,rseq)[AVPs]
      ------------------------------------------------------
         <-----        PANA-Ping-Request(p,q)[Session-Id, MAC]
         ----->        PANA-Ping-Answer(q+1,p)[Session-Id, MAC]

        Figure 8: Example Sequence for PAA-initiated liveness test

[6] In section 4.6:

Remove:

  o  Re-authentication based on the PANA-Reauth exchange is performed.

[7] In Section 4.10:

Change:

   PANA peer can use PANA-Reauth-Request message to
   verify the disconnection before taking an action.

   The session lifetime parameter is not related to the transmission of
   PANA-Reauth-Request messages.  These messages can be used for
   asynchronously verifying the liveness of the peer and enabling
   mobility optimizations.  The decision to send PANA-Reauth-Request
   message is taken locally and does not require coordination between
   the peers.

To:

   PANA peer can use PANA-Ping-Request message to
   verify the disconnection before taking an action.

   The session lifetime parameter is not related to the transmission of
   PANA-Ping-Request messages.  These messages can be used for
   asynchronously verifying the liveness of the peer.  The decision 
   to send PANA-Ping-Request message is taken locally and does not 
   require coordination between the peers.

[8] In Section 6.4:

Change:

                 PANA-Reauth-Request         <------->
                 PANA-Reauth-Answer          <------->

To:

                 PANA-Ping-Request           <------->
                 PANA-Ping-Answer            <------->

[9] New text for Section 6.4.9 and 6.4.10:

6.4.9  PANA-Ping-Request (PPR)

   PANA-Ping-Request (PPR) is either sent by the PaC or the PAA.

         PANA-Ping-Request ::= < PANA-Header: 5, REQ >
                       < Session-Id >
                    *  [ AVP ]
                   0*1 < MAC >

6.4.10  PANA-Ping-Answer (PPA)

   PANA-Ping-Answer (PPA) is sent in response to a
   PANA-Ping-Request.

         PANA-Ping-Answer ::= < PANA-Header: 5 >
                       < Session-Id >
                    *  [ AVP ]
                   0*1 < MAC >

[10] In Section 6.6:

Change:

 Attribute Name      | PRAR | PRAA | PTR | PTA | PER | PFER | PFEA |

To:

 Attribute Name      | PPR  | PPA  | PTR | PTA | PER | PFER | PFEA |

[11] In Section 7:

Change:

         PANA-Reauth-Request (PRAR)

To:

         PANA-Ping-Request (PPR)

Change:

   The last two messages, PRAR and PTR are sent either by PaC or
   PAA.

To:

   The last two messages, PPR and PTR are sent either by PaC or
   PAA.

[12] In Section 9.g:

Change:

   A disconnect may also be detected earlier by using PANA
   reauthentication messages.

To:

   A disconnect may also be detected earlier by using PANA
   ping messages.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 19 Aug 2004 12:23:20 -0400

Hi Alper,

The suggested changes basically looks good.  Please see my minior
comments below.

>          +  PANA-Termination-Request.

Should PANA-Ping-Request be allowed in discovery and initial handshake
phase?

>          +  PANA-Termination-Request.

Should PANA-Ping-Request be allowed in authentication phase?

Regards,

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 19 Aug 2004 12:45:18 -0700

> Should PANA-Ping-Request be allowed in authentication phase?

I thought about these. I decided to let the ping behavior handle this
automatically. If there is an established pana session on the peer, it
will respond. Otherwise, ping request will be silently discarded. This
behavior can be followed in any state. [Also, PDI and PAR/PAN can be
sent even when there is an established PANA session. Hence ping should
work in that case.]

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 19 Sep 2004 19:37:05 -0400

> sent even when there is an established PANA session. Hence ping should

It is probablly easier to do that at the receiving side of the ping
request, but what about transmitting side?  If we allow a PAA or a PaC
to send a PANA-Ping-Request and receiving a PANA-Ping-Answer between
two consecutive PANA-Auth-Request/Answer exchanges in authentication
phase, it would complicate the state machines (probably one additional
state is needed to support this case in the PaC and PAA state
machines).  I have a similar observation for PANA pinging in discovery
and initial handshake phase.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 19 Aug 2004 16:47:57 -0700

Yoshi,

I never thought we would need to deal with PANA-ping in the state
machine.
I perceive it as a tool that can be used asynchronous to the state
machine, and does not automatically impact the state machine. [Sure,
PANA implementation can use PANA ping to discover dead-peer, just like
it could use ICMP echos, or L2 indications]. If a state had explicitly
called for using PANA-ping, then we must have incorporated it in the
state machine.

Alper

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Sunday, September 19, 2004 4:37 PM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; [email-masked]
> Subject: Re: [Pana] Issue 105: Inconsistent and unclear usage of
"reauth"
> messages

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 19 Sep 2004 20:11:57 -0400

In draft-ohba-pana-statemachine-00.txt, there is a state WAIT_PRAA
(which transits only from OPEN state) in both PaC and PAA state
machines to wait for PANA-Reauth-Answer after sending
PANA-Reauth-Request.  Since we are replacing PANA-Requth-* with
PANA-Ping-*, the WAIT_PRAA state would be replaced with WAIT_PPA.  I
am afraid if we need additional transitions to the WAIT_PPA state from
several states, it would complicate the state machines and I am
wondering what is the benefit of adding such complexity.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 20 Aug 2004 10:35:07 -0700

I'm trying not to limit use of PANA-ping to only OPEN state. I think we
don't have to incorporate PANA-ping to the state machine. It can have
its own state machine (if that makes sense), disjoint to the main one.

Alper

> Sent: Sunday, September 19, 2004 5:12 PM
> To: Alper Yegin
"reauth"
> > > > automatically. If there is an established pana session on the
peer,
> > it
> > > > will respond. Otherwise, ping request will be silently
discarded.
> > This

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 20 Sep 2004 14:43:34 -0400

> its own state machine (if that makes sense), disjoint to the main one.

The disjointing approach does not make much sense to me if PANA is
designed as a lock-step protocol for which multiple outstanding
requests are not allowed.  For example, EAP is a lock-step protocol.
If PANA is designed to be a non-lock-step protocol, a ping request can
be sent even if there is an outstanding request, for which case
disjointing would make sense.

Question: Is PANA a lock-step protocol?

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 20 Aug 2004 12:45:14 -0700

> Question: Is PANA a lock-step protocol?

I'm not sure if this is the right question. I think we should be trying
to answer if PANA-ping is ever needed when the sender is not in OPEN
state. 

I see at least two cases:
a- using PANA-ping for debugging. In that case you want to be able to
use it in any state (e.g., in the middle of a hung WAIT_* state).
b- to discover the state of the peer (e.g., after a crash and reboot.
Before the crash, the sender might have been in a state other than
OPEN).

Alper

> > > > PANA implementation can use PANA ping to discover dead-peer,
just
> > like
> > > > > > > Should PANA-Ping-Request be allowed in discovery and
initial
> > > > handshake
> > > > > > I thought about these. I decided to let the ping behavior
handle
> > > > this
> > > > > > behavior can be followed in any state. [Also, PDI and
PAR/PAN
> > can be
> > > > > > sent even when there is an established PANA session. Hence
ping
> > > > should
> > > > > request, but what about transmitting side?  If we allow a PAA
or a
> > PaC

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 20 Oct 2004 16:29:36 -0400

> use it in any state (e.g., in the middle of a hung WAIT_* state).

I think we can use other tools for debugging as we normally do for
other protocol implementations.

> Before the crash, the sender might have been in a state other than

Can't a simple method "wait for the current authentication session to
fail" be used here?  I do not have a serious demand on doing liveness
test for an incomplete session (but others may have...).

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 23 Aug 2004 11:39:43 -0700

> other protocol implementations.

I'm thinking of this as similar to PPP echo-request/reply. 

> fail" be used here?  

The discovery can be much faster by using the ping if we didn't have to
wait for timeouts.

> I do not have a serious demand on doing liveness

I think there are many ways this ability (to send PANA-ping at any time)
is useful. We might not be able to exhaust them right now. I just don't
want to limit its usage to certain states. Unless it complicates
anything I don't see why not have this flexibility.

Alper

> > > > > PANA-Ping-*, the WAIT_PRAA state would be replaced with
WAIT_PPA.
> > I
> > > > > am afraid if we need additional transitions to the WAIT_PPA
state
> > from
> > > > > > machine, and does not automatically impact the state
machine.
> > [Sure,
> > > > > > called for using PANA-ping, then we must have incorporated
it in
> > the
> > > > > > > Subject: Re: [Pana] Issue 105: Inconsistent and unclear
usage
> > of
> > > > > > > > automatically. If there is an established pana session
on
> > the
> > > > > > > It is probablly easier to do that at the receiving side of
the
> > > > > > > to send a PANA-Ping-Request and receiving a
PANA-Ping-Answer
> > > > between
> > > > > > > phase, it would complicate the state machines (probably
one
> > > > additional
> > > > > > > machines).  I have a similar observation for PANA pinging
in
> > > > discovery

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 23 Oct 2004 18:08:20 -0400

> I'm thinking of this as similar to PPP echo-request/reply. 

PPP echo is allowed only for its LCP Opened state, not for arbitrary
state.

> The discovery can be much faster by using the ping if we didn't have to

If rebooting events are rare, I don't much care about timeouts for
rare events.

> anything I don't see why not have this flexibility.

I have a bit concern on the complexity needed to support this
flexibility from the state machine point of view, and my previous
question on lock-step operation relates to that.  I don't think just
having an independent state machine for pinging works for a protocol
that is designed under lock-step operations.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 23 Aug 2004 15:32:10 -0700

> PPP echo is allowed only for its LCP Opened state, not for arbitrary

I noticed that. But unless there is a technical reason, I don't think we
should inherit the same limitations.

> that is designed under lock-step operations.

I still don't understand the complexity on the state machine. My
recommendation is not to include PANA-ping in the (main) state machine.

And being lock-step was never a design goal or requirement. If this
addition is breaking the lock-step nature, I don't see a problem, unless
there was a benefit of being lock-stepped and now we are losing it. Are
we?

Alper

usage
> > > > > > > several states, it would complicate the state machines and
I
> > am
> > > > > > > > I never thought we would need to deal with PANA-ping in
the
> > > > state
> > > > > > > > machine.
> > > > > > > > I perceive it as a tool that can be used asynchronous to
the
> > > > > > > > it could use ICMP echos, or L2 indications]. If a state
had
> > > > > > explicitly
> > > > > > > > > > > Should PANA-Ping-Request be allowed in
authentication
> > > > > > > > > request, but what about transmitting side?  If we
allow a
> > PAA
> > > > > > > > > state is needed to support this case in the PaC and
PAA

---

From: James Carlson <[email-masked]>
Date: Tue, 24 Aug 2004 07:03:44 -0400

> should inherit the same limitations.

Until LCP is Opened, you don't have a negotiated Magic-Number option,
so there's some ambiguity about what to put in each message and how to
verify the response.  Plus, while you're actively negotiating LCP,
there doesn't seem to be a reason to do an LCP Echo-Request -- you
know from LCP alone whether the peer is responding or not.

I think there may also have been a concern about using too many
different optional code numbers too early in the game.  Early
incarnations of PPP were a bit draconian about encountering bad codes
or LCP Code-Reject: they'd shut down the link.  Thus, unless it was
really absolutely necessary for operation of the link, it was left
until after LCP was done.

None of the above probably applies here.

-- 
James Carlson, IP Systems Group                <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 24 Oct 2004 10:08:55 -0400

Hi Alper,

Please see my analysis below.

By not including PANA-ping in the main state machine, I presume that
PANA-ping behavior is described in a separate state machine such as a
pana-ping state machine.  There are two design choices on how to
define the pana-ping state machine depending on whether PANA is
designed as a lock-step protocol or not.

1.  Lock-step PANA-ping

Since it is lock-step, it is prohibited to send a new request if there
is an outstanding request.  The pana-ping state machine and the main
state machine need to coordinate to guarantee this nature, probably by
defining a variable that is shared between the pana-ping state machine
and the main state machine to indicate whether there is an outstanding
request.  Also, exclusive write access to the variable from the two
state machines would be needed.  But how can such an exclusive write
access in the two state simply be described in the two state machines?
Or is there other way to describe the coordination in a simple manner?

2. Non-lock-step PANA-ping

In this case, it is allowed to send a new request regardless of
whether there is an outstanding request.  This means that there can be
multiple outstanding requests.  Since the answers for the outstanding
requests can arrive out of order, the requester needs to buffer
out-of-order answers and re-order them before passing them to the
state machines.  The re-ordering requirement also needs a
change to sequence number handling.  Especially the acceptable
sequence number range in condition (ii) of the following text in
section 4.1.4 would need to be changed to consider re-ordering.

"
   o  When a message is received, it is considered valid in terms of
      sequence numbers if and only if (i) its tseq is greater than the
      tseq of the last accepted message and (ii) its rseq falls in the
      range between the tseq of the last acknowledged message and the
      tseq of the last transmitted message.
"

The re-ordering requirement seems to be a significant change to the
PANA protocol.

Also consider the following case:

- A requester sends a request X.

- No answer for X is received for a while.

- The requester sends a PANA-Ping-Request for peer liveness test.

- A PANA-Ping-Answer is received from the peer before an answer for X,
but it is handled as an out-of-order packet and has to be buffered to
wait for an answer for X.

This would mean that non-lock-step PANA-ping and lock-step PANA-ping
are not much different in their high-level behaviors.  At least I can
say that non-lock-step PANA-ping does not pay for the incurring cost
to change the PANA protocol to support re-ordering and we should not
do that.

Regards,

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 24 Aug 2004 11:21:31 -0700

Hi Yoshi,

Thank you for the analysis. I was thinking about something like 2 but I
totally missed the sequence numbering issue. While thinking about it,
some other issue came to my mind. I think these are related, let me
describe it.

  PaC       PAA   seq.nos.
1. <---------      x,y
2. --------->      y+1,x
3. ---+            y+2,x
4.    |  +---      x+1,y+1
   <--|--+
      +----->

Both message 3 and 4 would be dropped by the recipients. This situation
is possible even without PANA-ping, as we allow PaC to generate other
types of packets on its own (e.g., termination request, update request).

Alper

> Sent: Sunday, October 24, 2004 7:09 AM
> To: Alper Yegin
"reauth"
> > > > > > b- to discover the state of the peer (e.g., after a crash
and
> > > > reboot.
> > > > > > Before the crash, the sender might have been in a state
other
> > than
> > > > > > OPEN).
> > > > >
> > > > > Can't a simple method "wait for the current authentication
session
> > to
> > > > > fail" be used here?
> > > >
> > > > The discovery can be much faster by using the ping if we didn't
have
> > to
> > > > I think there are many ways this ability (to send PANA-ping at
any
> > time)
> > > > is useful. We might not be able to exhaust them right now. I
just
> > don't
> > > > > > > > > In draft-ohba-pana-statemachine-00.txt, there is a
state
> > > > WAIT_PRAA
> > > > > > > > > (which transits only from OPEN state) in both PaC and
PAA
> > > > > > > > > PANA-Reauth-Request.  Since we are replacing
PANA-Requth-*
> > > > with
> > > > > > > > > > > On Thu, Aug 19, 2004 at 12:45:18PM -0700, Alper
Yegin
> > > > wrote:
discovery
> > and
> > > > > > > > > > > > behavior can be followed in any state. [Also,
PDI
> > and
> > > > > > PAR/PAN
> > > > > > > > can be
> > > > > > > > > > > > sent even when there is an established PANA
session.
> > > > Hence
> > > > > > > > > > > two consecutive PANA-Auth-Request/Answer exchanges
in

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Aug 2004 16:29:04 -0400

> types of packets on its own (e.g., termination request, update request).

Since the above example does not show the message type for each
message, so it would be difficult to discuss the issue on
non-lock-step vs. lock-step operations based on the above example.
But message 3 and 4 seem to be valid at least *in terms of sequence
numbers*.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 24 Aug 2004 14:47:54 -0700

Yoshi,

> > 4.    |  +---      x+1,y+1

Imagine 3 is a termination request (PTR), and 4 is an authentication
request (PAR). I'm trying to point out a problem with the current design
(even without PANA-ping). 

Do you see the same problem? 

The solution to this may help answer what to do with PANA-ping question.

Alper

> > > > > > > I think we can use other tools for debugging as we
normally do
> > for
> > > > > question on lock-step operation relates to that.  I don't
think
> > > > addition is breaking the lock-step nature, I don't see a
problem,
> > unless
> > > > there was a benefit of being lock-stepped and now we are losing
it.
> > Are
> > > > > > > > > > > several states, it would complicate the state
machines
> > > > > > > > > > > On Thu, Aug 19, 2004 at 04:47:57PM -0700, Alper
Yegin
> > > > wrote:
> > > > > > > > > > > > Yoshi,
> > > > > > > > > > > >
> > > > > > > > > > > > I never thought we would need to deal with
PANA-ping
> > > > > > > > > > > > PANA implementation can use PANA ping to
discover
> > > > dead-peer,
> > > > > > > > just
> > > > > > > > > > like
> > > > > > > > > > > > it could use ICMP echos, or L2 indications]. If
a
> > > > > > > > > > > > > Subject: Re: [Pana] Issue 105: Inconsistent
and
> > > > unclear
> > > > > > > > > > > > > > I thought about these. I decided to let the
ping
> > > > > > behavior
> > > > > > > > handle
> > > > > > > > > > > > this
> > > > > > > > > > > > > > automatically. If there is an established
pana
> > > > session
> > > > > > on
> > > > > > > > the
> > > > > > > > > > peer,
> > > > > > > > > > > > it
> > > > > > > > > > > > > > will respond. Otherwise, ping request will
be
> > > > silently
> > > > > > > > > > > > > It is probablly easier to do that at the
receiving
> > > > side of
> > > > > > > > > > > > > state is needed to support this case in the
PaC
> > and
> > > > PAA
> > > > > > state
> > > > > > > > > > > > > machines).  I have a similar observation for
PANA
> > > > pinging

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Aug 2004 19:10:59 -0400

> (even without PANA-ping). 

According to draft-ohba-pana-statemachine-00.txt:

- A PTR is allowed to be sent only in OPEN state.  So the PaC is
assumed to be in OPEN state before sending message 3 and in SESS_TERM
state after sending message 3.  Message 4 (PAR) will be dropped by the
PaC since PAR is not expected in SESS_TERM state.

- The PAA is assumed to be somehow in WAIT_PAN state after sending
message 4 (PAR).  Message 3 (PTR) will be dropped by the PAA since PTR
is not expected in WAIT_PAN state.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 24 Aug 2004 16:33:45 -0700

> - A PTR is allowed to be sent only in OPEN state.  

Yes, that's fine. PaC and PAA can be in OPEN state before message 3.
(imagine 4 is for EAP authentication before the current PANA session
lifetime expires).

> So the PaC is

Even before these packets are dropped due to state mismatch as you
described, they'd be dropped due to sequence number checks. Whatever the
reason is, they should not cancel each other. If they do, depending on
the retransmission timers, they can keep doing this and finally tear
down the session. This is a bug.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Aug 2004 20:42:08 -0400

On Tue, Aug 24, 2004 at 04:33:45PM -0700, Alper Yegin wrote:
> described, they'd be dropped due to sequence number checks. 

As I commented in a previous mail, they are valid at least in terms of
sequence numbers.  But your point indicated below is still valid.

> Whatever the

It seems that this is a race condition between EAP re-authentication
initiated by one entity and session termination initiated by the other
entity.  I agree with you that this is a bug and should be resolved.
I think the latter (session termination initiated by the other entity)
should supersede the former (EAP re-authentication initiated by one
entity).

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 24 Aug 2004 18:19:27 -0700

> should supersede the former (EAP re-authentication initiated by one

I'm not sure what you mean by "supersede", or how it solves the problem.

This is the same non-lock-step issue with PANA-ping. If only one side
(PAA) generates the requests, there is no problem. If both sides can
asynchronously generate requests, the current sequence number checking
scheme fails (prevents asynchronous transmission, dropping valid
packets).

If we go back to the original intent of sequence numbering, it is for
orderly delivery of EAP messages. If all messages were EAP-driven, that
would be fine because all requests are generated by the PAA. But that's
not the case.

One solution could be to enforce orderly delivery only among
EAP-carrying messages, and let the other (PANA management) messages not
have to fit that scheme. What would be the impact on the design? [and of
course, are there any other solutions?]

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Aug 2004 23:53:51 -0400

> I'm not sure what you mean by "supersede", or how it solves the problem.

I mean that if an entity that has sent a message that initiates EAP
re-authentication (i.e., a PSA sent by a PAA in OPEN state or a PDI
sent by a PaC in OPEN state) receives a PTR, then it SHOULD respond
with a PTA and delete the session.

> scheme fails (prevents asynchronous transmission, dropping valid

By re-reading my analysis, I realized that the meaning of
"non-lock-step" was ambiguous.  "non-lock-step" meant that one side
can generate multiple outstanding requests.  For both lock-step and
non-lock-step models both sides can asynchronously generate requests.
So the above race condition is different from the non-lock-step issue
with PANA-ping.

> course, are there any other solutions?]

I am not sure what solution you mean by "let the other (PANA
management) messages not have to fit that scheme".

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 25 Aug 2004 15:38:54 -0700

Yoshi,

I think I'm understanding some of the issues.

1- I raised an issue with the sequencing, and gave an example how it
creates a problem when PaC and PAA can asynchronously send requests to
each other. I was wrong. There is no problem with the sequence numbers,
the packets are not really discarded due to them. [I think you've been
trying to tell me they were OK.]

2- You raised an issue with a peer having multiple outstanding requests
(for allowing PANA-ping-requests when there is already an outstanding
request). I agree that complicates the sequencing. 

Besides a peer might not need to send a PANA-ping if there is already an
outstanding request. Because a response to that is as good as pinging
the other peer. 

So I agree that we don't have to accommodate for transmission of a
PANA-ping-request when there is a pending request.

3- But, how about allowing the "reception" of a PANA-ping-request when
the peer has an outstanding request? I think that should be fine. The
receiver should simply respond to it, and that does not impact the state
machine imo (no state change for simply responding to a ping request).

4- PANA-termination-request (PTR) should be accepted in most (all?)
states,
even if the receiver has a pending request. We may have to limit its use
to only after the first successful PANA-Bind. Otherwise, it may be used
for DoS on the PaC that is trying to get authenticated for the first
time.

What do you think?

Alper 

> Sent: Tuesday, August 24, 2004 8:54 PM
> To: Alper Yegin
"reauth"

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 26 Aug 2004 10:14:46 -0400

Alper,

> trying to tell me they were OK.]

OK.

> request). I agree that complicates the sequencing. 

OK.

> machine imo (no state change for simply responding to a ping request).

Under the current sequence number scheme it is fine.  However, if we
consider using the same sequence number for retransmitted messages as
we are going to agree as a resolution for Issue 106, I think there is
a problem with allowing the reception of a PPR when the peer has an
outstanding request.  Please see the following example in which the
same sequence number for retransmitted messages:

Suppose that a PAA that has an outstanding PANA-Auth-Request with
tseq=x receives a PANA-Ping-Request from a PaC and returns a
PANA-Ping-Answer giving tseq=x+1 and the PaC receives the answer.
Then the retransmission timer expires and the PAA retransmit the
outstanding PAR with tseq=x.  The PaC will drop the retransmitted PAR
because the received tseq(=x) is less than the last accepted
tseq(=x+1).

This problem is due to sharing the same sequence number space among
requests and answers sent by one side.  It is probably better and
simpler to allocate one sequence number space to requests from PaC and
the other sequence number space to requests from PAA, and make answers
carry the sequence numbers of the corresponding requests, like the
sequence number scheme taken by IKEv2.  By doing this, we do not need
to carry two sequence numbers in each message any more, but there are
still two sequence number spaces as the current PANA sequcen number
scheme.

> for DoS on the PaC that is trying to get authenticated for the first

For the receiving side of a PTR, it is OK.  But if the sender can send
PTR at any state, then we would still encounter issue 2 above.  The
same thing for sending PANA-Ping-Request at any state.  I still don't
know an easy way when we design state machines to allow sending a PTR
or a PPR at any state without conflicting with other requests sent by
the same node.  I still prefer allowing a PTR or a PPR to be sent in
OPEN state only.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 26 Aug 2004 19:38:54 -0700

> because the received tseq(=x) is less than the last accepted

Good observation.

> still two sequence number spaces as the current PANA sequcen number

Susan Thomson has a proposal on that. I'll relay her proposal soon (I'm
waiting for her permission to forward her e-mail to the list).

> same thing for sending PANA-Ping-Request at any state.  

I agree. My comment is about accepting a request on the receiving peer,
not transmitting the request. 

> I still don't

I think that's fine.

Alper

> > > > > initiated by one entity and session termination initiated by
the
> > > > > should supersede the former (EAP re-authentication initiated
by
> > > > If we go back to the original intent of sequence numbering, it
is
> > for
> > > > orderly delivery of EAP messages. If all messages were
EAP-driven,
> > that
> > > > EAP-carrying messages, and let the other (PANA management)
messages
> > not

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Aug 2004 09:23:37 -0700 (PDT)

> still two sequence number spaces as the current PANA sequcen number

I think this makes sense.
I does assume that each request have a corresponding response. Is this the
case in the current PANA set of messages?

  Erik

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 27 Aug 2004 11:29:25 -0400

> case in the current PANA set of messages?

PANA-PAA-Discover and PANA-Error do not have corresponding responses.  

- Since PANA-PAA-Discover is specially handled (the sequence number is
always zero), I think we don't need to define a corresponding response
for it.

- For PANA-Error, I think we needs to define a corresponding response.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 27 Aug 2004 10:45:07 -0700

Is it a requirement of this sequence numbering scheme that each message
that is not a response must generate a response from the receiving peer?

[the current spec says PANA-PAA-Discover uses sequence number 0. But I
suspect it is not taking into account that this message is also used by
PaC to initiate subsequent re-authentications. So maybe we shouldn't
really reset the sequence number like that in the middle of an ongoing
PANA session.]

Alper

> > I does assume that each request have a corresponding response. Is
this

---

From: Alper Yegin <[email-masked]>
Date: Fri, 27 Aug 2004 13:14:34 -0700

Let's get back to the resolution of Issue 105... Putting the sequence
numbering re-design aside (saving it for issue 106), here is what we
have for Issue 105. 

Note that only update #3 has changed since take 1.

[1] In Section 3:

Change:

To:

   In addition, PANA allows re-authentication of the PaC and PAA by
   allowing any one of them to initiate an EAP authentication during
   an on-going PANA session. Refreshing the session and cryptographic
   keys are possible reasons to engage in re-authentication.

[2] In Section 3.1:

Change:

To:

Change:

To:

[3] In Section 4.1.7:

Updated text: 

   o  The message type is one of the expected types in the current
      state.  Specifically the following messages are unexpected and
      invalid:

         +  PANA-Termination-Request and PANA-Ping-Request.

         +  PANA-Bind-Request.

         +  PANA-Update-Request.

         +  PANA-PAA-Discover.

         +  PANA-Update-Request.

         +  PANA-Start-Request after the PaC receives the first valid
            PANA-Auth-Request.

         +  PANA-Termination-Request before the PaC receives the first
            successful PANA-Bind-Request.

      *  After successful PANA authentication:

         +  PANA-Start-Request as well as a non-duplicate
            PANA-Bind-Request (see section Section 4.7 for definition of
            duplicate requests).

         +  PANA-PAA-Discover without a Session-Id AVP.

      *  In termination phase:

         +  PANA-PAA-Discover.

         +  All requests but PANA-Termination-Request.

4.4  Re-authentication

      PaC      PAA  Message

4.5. Liveness Test

[6] In section 4.6:

Remove:

[7] In Section 4.10:

Change:

To:

[8] In Section 6.4:

Change:

To:

[10] In Section 6.6:

Change:

To:

[11] In Section 7:

Change:

To:

         PANA-Ping-Request (PPR)

Change:

To:

[12] In Section 9.g:

Change:

To:

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 29 Aug 2004 22:51:44 -0400

The text looks good.  I found one typo.

>    An already authenitcation PANA session can enter an authentication 

I guess the above text should be "An already established PANA session..."

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 29 Aug 2004 23:33:41 -0400

> that is not a response must generate a response from the receiving peer?

I think so.  If there is some message for which a corresponding
response is not defined, then an endpoint cannot determine the next
sequence number to receive (due to a possible sequence number gap when
such a message is lost).  If we want to make some message
unacknowledged, then an endpoint would need to accept a range of
sequence numbers for the next message, but I think defining such a
range is difficult.

I think the "two sequence number spaces but one sequence number in
message header" scheme like IKEv2 works only if a protocol is defined
as a reliable protocol, again like IKEv2.

> really reset the sequence number like that in the middle of an ongoing

When a PaC sends a PDI to initiate re-authentication, it carries the
sequence number 0, but in subsequent PANA message exchange the
previous sequence numbers are inherited according to section 4.4.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 30 Aug 2004 10:48:20 -0700

Fixed the problem in [4]...

[1] In Section 3:

Change:

To:

[2] In Section 3.1:

Change:

To:

Change:

To:

[3] In Section 4.1.7:

Updated text: 

         +  PANA-Bind-Request.

         +  PANA-Update-Request.

         +  PANA-PAA-Discover.

         +  PANA-Update-Request.

      *  In termination phase:

         +  PANA-PAA-Discover.

4.4  Re-authentication

   An already established PANA session can enter an authentication 

      PaC      PAA  Message

4.5. Liveness Test

[6] In section 4.6:

Remove:

[7] In Section 4.10:

Change:

To:

[8] In Section 6.4:

Change:

To:

[10] In Section 6.6:

Change:

To:

[11] In Section 7:

Change:

To:

         PANA-Ping-Request (PPR)

Change:

To:

[12] In Section 9.g:

Change:

To:

---

From: Alper Yegin <[email-masked]>
Date: Mon, 30 Aug 2004 11:48:53 -0700

> sequence number to receive 

Why does it have to determine the next sequence number to receive?
All we care is orderly delivery. And for that, we can simply compare if
the new sequence number is greater than or equal to previous one. [This
has the potential blind DoS vulnerability, which should be taken care of
by having to match the randomly assigned Session ID]

Furthermore, in addition to PDI and PER, I think PAR also has issues.
PAR is not delivered reliably at the PANA layer. So, a single PAR can be
lost, and the EAP-generated retransmission would not have the same PANA
sequence number when transmitted. So, a legitimate gap in sequence
number is possible.

> (due to a possible sequence number gap when

I didn't think so. I think this part is underspecified in the text. What
would be the logic behind PDI always using 0? I understand the very
first PDI, but the subsequent PDIs (which are unicasted btw) could
continue the ongoing sequence [given that we don't force
request-response with matching sequence numbers on all types of
messages].

Alper

> > > > > simpler to allocate one sequence number space to requests from
PaC
> > > > > sequence number scheme taken by IKEv2.  By doing this, we do
not
> > need
> > > > > to carry two sequence numbers in each message any more, but
there
> > are

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 30 Aug 2004 19:32:39 -0400

> by having to match the randomly assigned Session ID]

I think that the simple comparison scheme is too vulnerable to DoS
attack even having to match the Session ID.  The attacker can see one
packet to obtain the Session ID and sequence number and later on it
can blindly inject a bogus message with the expected Session ID and an
expected sequence number at about 50% probability.  This is the reason
for carrying rseq (receiving sequence number) in the current PANA
sequence number scheme.

> Furthermore, in addition to PDI and PER, I think PAR also has issues.

Yes, I think so.

> sequence number when transmitted. So, a legitimate gap in sequence

Yes.  I am trying to analyze the effect of allowing the legitimate gap
in an IKEV2-like sequence number scheme, but I have yet come up with a
good solution to allow the gap.  A safer solution is to move the
responsibility of EAP message retransmission from EAP to PANA, but I
don't have a strong justification for it for now, either.

> request-response with matching sequence numbers on all types of

I understand it. I think we should not use the 0 sequence number for
PDI when it is sent for re-authentication (and such a PDI should 
be protected with a MAC AVP when a PANA SA is available.)

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 30 Aug 2004 17:26:34 -0700

> expected sequence number at about 50% probability.  

This is a possible threat when:
[a]- the adversary can snoop traffic long enough to catch one packet,
but not always (if it could always snoop, not even having rseq helps as
the adversary can synchronize on both rseq/tseq all the time).
[b]- The adversary does not want to immediately launch an attack. (but
it better be before the PANA SA is established).

I'm not sure how feasible condition [a] is, and why an adversary would
want to wait when there is a possibility of missing the chance ([b]).

> This is the reason
...

> be protected with a MAC AVP when a PANA SA is available.)

Note that PDI is not a request-answer type. It does not have an answer
that can copy the sequence number from PDI either. (If the sequence
number of generated PAR is copied from the PDI, that'd disturb the
sequencing on the PAA). 

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 30 Aug 2004 21:01:59 -0400

> the adversary can synchronize on both rseq/tseq all the time).

The adversary could always snoop traffic long enough to catch one
packet.  The difficulty level of synchronization can be different
depending on the sequence number scheme in use.  With having rseq, the
adversary needs much more effort to synchronize on both rseq/tseq than
on tseq-only (50%).

> it better be before the PANA SA is established).

In tseq-only solution, the adversary does not have to immediately
compose and transmit a bogus packet, which means that a device with
poor CPU power can easily launch the attack.

> number of generated PAR is copied from the PDI, that'd disturb the

You are right.  Then I think using 0 sequence number for PDI might be
a reasonable solution if we don't define PDI as a request-answer type
message.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 30 Aug 2004 22:11:56 -0400

The proposed text is now available in snapshot -06a.

Regards,

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 30 Aug 2004 21:47:43 -0700

> adversary needs much more effort to synchronize on both rseq/tseq than

If the adversary can snoop one packet and decides to launch the attack
immediately, I don't see any difference between having to deal with two
sequence numbers vs. one. If it captures (tseq, rseq), it will just
spoof (rseq+1, tseq) in the reverse direction with some appropriate
payload.

> poor CPU power can easily launch the attack.

If the adversary is not fast enough to compose the immediate next packet
before the legitimate peer does, why not try to compose couple packets
later and cache it. And when the time comes (detected by snooping) just
transmit the canned packet. 

...

> a reasonable solution if we don't define PDI as a request-answer type

Or, if we don't require each non-response message to be treated as a
request and expect a response (with matching seq. no), then PDI can
continue the on-going sequence numbering. 

...

I'm still failing to see the seriousness of the DoS issue. But
nevertheless, if you have a low-cost solution, we should use it. 

[just to make sure we are on the same page, the current direction is:
- only one seq no is included in each message, but each peer has its own
seq no for the non-answer messages it generates.
- answers copy the seq no from the requests.

The issue is:
- There are messages that do not (or may not) generate "answers", such
as PDI, PER, and PAR. 
]

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 30 Aug 2004 21:50:26 -0700

...

...

The issue is:

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 31 Aug 2004 09:17:25 -0400

> spoof (rseq+1, tseq) in the reverse direction with some appropriate

Yes, that is true with the "snoop and immediate launch" condition.

> transmit the canned packet. 

To make that attack succeed in tseq-rseq scheme, the adversary still
need to immediately transmit the pre-composed packet with snooping the
latest conversation and do it before the legitimate peer can send
another packet.  I would say that not all cheap devices can be fast
enough to do that, and there is a difference in the difficulty levels
of synchronization between tseq-only scheme and tseq-rseq scheme.  To
me this is not a small difference and I have been consistent on this
point since the initial design phase.  I would feel more comfortable
with a reliable protocol that has notion of sequence number window
when an IKEv2-like sequence number scheme is used.

> nevertheless, if you have a low-cost solution, we should use it. 

Please see my comment above.

> - There are messages that do not (or may not) generate "answers", such

Yes, I am on that direction.

Yoshihiro Ohba