Subject: Re: [Pana] New: [issue98] Lost answer problem

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 06 Jul 2004 00:06:51 -0400

Here is a proposed solution for the lost answer problem.

---------------------------------
Insert the following section.

"
Section 4.X  Retransmission of Duplicate Answers

Since PANA is designed over UDP, an answer as well as a request can be
lost.  In order to improve robustness against possible loss of
synchronization between a PaC and a PAA, the responder of a request
MAY send a duplicate answer to a duplicate request for which already
answered (as well as a fresh answer to a new request if any).  In
PANA, a duplicate PANA-Start-Request or PANA-Start-Answer message has
the same contents as the original request or answer, respectively.  A
duplicate request other than PANA-Start-Request has the same contents
as the original request except for the transmission sequence number
and a MAC AVP (if any).  Also, a duplicate answer other than
PANA-Start-Answer has the same contents as the original answer except
for the transmission and receiving sequence numbers and a MAC AVP (if
any).  Retransmission of a duplicate answer in response to a duplicate
request occurs in the following ways.

o When a PaC receives a duplicate PANA-Start-Request message for which
it has already answered, it MAY send a duplicate PANA-Start-Answer
message until it receives a valid PANA-Auth-Request message.

o When a PaC receives a duplicate PANA-FirstAuth-End-Request message
for which it has already answered, it MAY send a duplicate
PANA-FirstAuth-End-Answer message until it receives a valid
PANA-Auth-Request message for the second EAP authentication.

o When a PaC receives a duplicate PANA-Bind-Request message for which
it has already answered, it MAY send a duplicate PANA-Bind-Answer
message until it receives some hint provided outside the PANA protocol
(e.g., receipt of a secure association protocol message from an EP or
receipt of data traffic) indicating that the PAA has received a
PANA-Bind-Answer message.

o When a PaC or a PAA receives a duplicate PANA-Termination-Request
message for which it has already answered, it MAY send a duplicate
PANA-Termination-Answer message for a while before deleting the PANA
session.  The period to send duplicate PANA-Termination-Answer
messages may be a configurable parameter.
"

Regards,

Yoshihiro Ohba

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

---

From: Alper Yegin <[email-masked]>
Date: Mon, 12 Jul 2004 16:49:20 -0700

I'm trying to understand the issue...

> From Yoshihiro Ohba:
> --------------------
> There might be some cases in which a PaC or a PAA might need to send a
> duplicate answer to a retransmitted old request (as well as a fresh
> answer to a new request if any) considering that an answer message for
> an old request can be lost.  Without this, a PANA session may stall in
> a way that the requester keeps retransmitting the old request while
> the responder may keep discarding them with waiting for a new request.

There would not be any discarding due to sequence numbers. I guess the
only problem could be that the PaC has jumped to the next state in the
state machine as soon as it responded to a message, and in that state it
does not expect the same request it had already responded earlier. Is
that the issue?

Alper

> The cases are described below.
> 
> - When a PaC sends a PANA-Start-Answer message in response to a valid
> PANA-Start-Request message without a Cookie AVP, the answer message
> can be lost.  The PANA-Start-Request would be retransmitted.  To deal
> with the case, it might be better for the PaC to return a duplicate
> PANA-Start-Answer message after the PaC has been sent the first
> PANA-Start-Answer message until the PaC receives a valid
> PANA-Auth-Request message.
> 
> - When a PaC sends a PANA-FirstAuth-End-Answer message in response to
a
> valid PANA-FirstAuth-End-Request message (remember that a
> PANA-FirstAuth-End exchange is used for delimiting the first and
> second EAP authentications), the answer message may be lost.  The
> PANA-FirstAuth-End-Request would be retransmitted (with updating
> transmission sequence number).  To deal with the case, it might be
> better for the PaC to return a duplicate PANA-FirstAuth-End-Answer
> message (with updating transmission and received sequence numbers)
> after the PaC has been sent the first PANA-FirstAuth-End-Answer
> message until the PaC receives a valid PANA-Auth-Request message for
> the second EAP authentication.
> 
> - When a PaC sends a PANA-Bind-Answer message in response to a valid
> PANA-Bind-Request message, the answer message can be lost.  As as
> result, the PAA will retransmit the PANA-Bind-Request (but with using
> a different transmission sequence number).  To deal with the case, it
> might be better for the PaC to return a duplicate PANA-Bind-Answer
> message (but with using different transmission and received sequence
> numbers) for a while after the first PANA-Bind-Request was received.
> The same thing can also apply to a PANA-Address-Update-Answer message
> that is sent by a PaC.
> 
> - When a PaC or a PAA sends a PANA-Termination-Answer message in
> response to a valid PANA-Termination-Request message, the answer
> message can be lost.  As as result, the requester will retransmit the
> request (but with using a different transmission sequence number).  To
> deal with the case, it might be better for the sender of the answer to
> return a duplicate answer (with using different transmission and
> received sequence numbers) for a while after the first
> PANA-Termination-Request was received.  The same thing can also apply
> to a PANA-Reauth-Answer message that is sent by a PaC or a PAA.
> 
> Those could improve robustness of the PANA protocol against loss of
> answer message.
> 
> Comments?
> 
> Yoshihiro Ohba
> 
> ----------
> category: Technical
> document: draft-ietf-pana-pana-xx.txt
> messages: 335
> nosy: dforsber
> priority: Must Fix
> status: Pending
> title: Lost answer problem
> __________________________________________________
> PANA Issues <[email-masked]>
> <http://danforsberg.info:8080/pana-issues/issue98>
> __________________________________________________

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Jul 2004 21:31:54 -0400

> does not expect the same request it had already responded earlier. Is

Yes.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 12 Jul 2004 18:49:58 -0700

> > does not expect the same request it had already responded earlier.
Is

OK, then I think this is not a protocol issue and I'd propose discussing
this in the state machine I-D.  As long as the request is not rejected,
the PaC should be able to produce a response . [Last transmitted message
payload is already part of the session attributes. It can be partially
used for optimization if needed].

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 13 Jul 2004 06:18:06 -0400

On Mon, Jul 12, 2004 at 06:49:58PM -0700, Alper Yegin wrote:
> the PaC should be able to produce a response . 

I think it is a protocol matter to specify in which condition a
request should be accepted or rejected.  For example, the PANA
specification should be clear on what to do when a PaC receives a
previously received PBR for which it has already sent a PBA.

Yoshihiro Ohba

> [Last transmitted message

---

From: Alper Yegin <[email-masked]>
Date: Tue, 13 Jul 2004 10:48:20 -0700

> previously received PBR for which it has already sent a PBA.

The default action would be to respond to the request (unless there is a
statement in the draft that makes an exception).

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 13 Jul 2004 13:30:41 -0700

(re-posting......)

-----Original Message-----
From: Alper Yegin - SAIT 
Sent: Monday, July 12, 2004 1:55 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: Erik Nordmark's review comments #1

Hello,

Please see Erik's review comments on the base spec, framework, and IPsec
documents below. I've been holding on to these until we received the
more detailed ones, but they won't be coming in for another couple of
weeks. Until than, let's start processing these ones...	

Alper

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Wednesday, June 16, 2004 10:38 AM
To: Alper Yegin - SAIT
Cc: Erik Nordmark; [email-masked]
Subject: RE: PANA review request

So I did finish the read of the document set on Friday,
but I haven't typed up the comments and some of them are
extensive.

The quick summary is:
The framework seems to be in reasonable shape but the introduction
is lacking in that it doesn't give an overview of the solved problem
and it doesn't indicate which order the naive implementor or somebody
that is trying to understand PANA should read the different documents.

The ipsec doc is mostly ok. It should probably make the distinction
between
authentication (of a user) and per-packet authentication more clear.

The pana document has significant editorial problems; by the time I'd
read
up to and including the security considerations section I finally
understood
what the features are of the protocol; reading back to front instead of
front to back would have made it easier to understand.
So editorially it needs to be better at incremental disclosure.
For instance, talking about the features/functions up front without
mentioning the packet formats and bit fields (RFC 2461 tries to do this
and might be a reasonable approach). Then talk about the packets and
what
they are for (DHCPv6 has that type of info; basically a short paragraph
per
packet.)
The document also seems to have technical omissions. The top 4 are:
 - a session is not defined. Questions like who allocates the session
id,
   whether or not a session is bidirectional or unidirectional (with
different
   ids for both ends), and what happens to the session when
reauthenticating
   and when using the mobility optimization are unstated.
 - the usage of device ID seems confused because there are some device
IDs
   that are carried in packets (L2/L3 addresses) and others that are not
   (circuit ID) but most places in the document read as if circuit ids
are
   always carried in packets; there is even an EP device ID (which is
used
   to just carry the address of the EP). Furthermore, doesn't ipsec
per-packet 
   auth rely on identifying the packet based on something else (the
IPsec SA?).
   Would it be more clear if device ID had two subclasses: local device
ID
   (e.g., cirtcuit ID) and address device ID (which would be carried in
   packets)?
 - the reauth packets seem to have completely different functions
depending
   on the direction they are sent. In one direction it is a reauth
   and in the other direction it is a keepalive. (The document even uses
   the term "keepalive" somewhere I think.) Wouldn't it be clearer
   if these were different messages?
 - the retransmission text says that a retransmitted packet has a new
sequence
   number. This makes no sense to me.

I'll type up more complete comments later.

  Erik

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Jul 2004 15:43:20 -0400

> statement in the draft that makes an exception).

There would be the following exceptions:

o In discovery and initial handshake phase,

  - PTR and PRAR is rejected.
  - PBR is rejected.
  - PAUR is rejected.

o In authentication phase, 

  - PTR and PRAR is rejected.
  - PAUR is rejected.
  - PSR is rejected after PaC receives the first vaild PAR.

o After successful PANA authentication,

 - PSR as well as a non-duplicate PBR is rejected.
 - PDI without a Session-Id AVP (i.e., initial authentication) is rejected.

o In termination phase,

 - All requests but PTR is rejected.

I think both the default action as well as these exceptions should be
described in the specification.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 14 Jul 2004 14:17:53 -0700

Yoshi,

> described in the specification.

These are related to the "states". That's why I think the discussion
belongs to the state machine I-D. It can discuss definition of states,
how the session moves from one state to another, and how messages are
processed in each state (ignored, rejected, causes state change, etc.)
And all that pana specification can say is what it already says:

4.1.7 Message Validity Check

   When a PANA message is received, the message is considered to be
   invalid at least when one of the following conditions are not met:

   o  The message type is one of the expected types in the current
      state.

I think this is a more scalable and modular approach. 

Alper

---

From: Rafael Marin Lopez <[email-masked]>
Date: Thu, 15 Jul 2004 12:53:23 +0200

Hi Alper...

Sounds good for me.

NOTE: On the other hand,  will be [tseq of the last acknowledged 
message, tseq of the last transmitted message] included in draft instead 
of [tseq of the last acknowledged message + 1, tseq of the last 
transmitted message] finally or it is another issue?

Regards.

Alper Yegin wrote:

>Yoshi,
>
>  
>
>>>The default action would be to respond to the request (unless there
>>>      
>>>
>is a
>  
>
>> - PDI without a Session-Id AVP (i.e., initial authentication) is
>>    
>>
>rejected.
>  
>
>>o In termination phase,
>>

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Jul 2004 09:08:28 -0400

Hi Alper,

> I think this is a more scalable and modular approach. 

I want to make sure the relationship between the PANA specification
I-D and the PANA state machine I-D.

The suggested approach seems to indicate that the PANA state machine
I-D is a part of the "complete" set of specification.  (Otherwise,
pana-pana draft needs to specify what messages types are expected in
the current state, doesn't it?)

Note that the suggested approach is different from the approach taken
by RFC 3748 (EAP) and EAP state machine I-D.  RFC 3748 specifies
everything including which message should be accepted or rejected in
certain conditions and EAP state machine I-D is just another
representation of RFC 3748.

Yoshihiro Ohba

---

From: Rafael Marin Lopez <[email-masked]>
Date: Thu, 15 Jul 2004 15:44:38 +0200

Hi Alper, Yoshihiro see my comments inline.

>I-D and the PANA state machine I-D.
I get your point.

>representation of RFC 3748.
I would rather PANA draft specifies everything because in some sense
PANA state machine draft should be a reflection on PANA protocol draft
and not adding new additional information to clarify some aspects of
PANA protocol specification.

Regards.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 15 Jul 2004 12:17:26 -0700

> the current state, doesn't it?)

I went over your list of what is rejected (ignored?) in what state. They
looked intuitive to me, I mean things we don't need to spell out. Like
you cannot terminate a session before it starts, or you cannot
reauthenticate before the initial authentication is complete, etc. 

Maybe this is a subjective view. I'm trying to control the verbosity
level and document size without jeopardizing clarity. 

> representation of RFC 3748.

Can you give an example from the EAP spec on that? I'd like to better
understand how we are going to tackle this if we want to include text in
the PANA spec. An example text on PANA (for one message only) would be
useful too. I'd like to make sure we don't unintentionally end up
sliding state machine discussions into the base spec.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Jul 2004 17:57:22 -0400

Couple of examples in RFC 3748:

- On resending a Response in response to a duplicate Request

"
      If a peer receives a valid duplicate Request for which it has
      already sent a Response, it MUST resend its original Response
      without reprocessing the Request.  Requests MUST be processed in
      the order that they are received, and MUST be processed to their
      completion before inspecting the next Request.
"

- On Nak message rejection.

"
   A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request
   after an initial non-Nak Response has been sent.  Since spoofed EAP
   Request packets may be sent by an attacker, an authenticator
   receiving an unexpected Nak SHOULD discard it and log the event.
"

- On EAP-Success/Failure message rejection:

"
   Success and Failure packets MUST NOT be sent by an EAP authenticator
   if the specification of the given method does not explicitly permit
   the method to finish at that point.  A peer EAP implementation
   receiving a Success or Failure packet where sending one is not
   explicitly permitted MUST silently discard it.  By default, an EAP
   peer MUST silently discard a "canned" Success packet (a Success
   packet sent immediately upon connection).  This ensures that a rogue
   authenticator will not be able to bypass mutual authentication by
   sending a Success packet prior to conclusion of the EAP method
   conversation.
"

- On prohibition of mixing Requests with different types.

"
   Once a peer has sent a Response of the same Type as the initial
   Request, an authenticator MUST NOT send a Request of a different Type
   prior to completion of the final round of a given method (with the
   exception of a Notification-Request) and MUST NOT send a Request for
   an additional method of any Type after completion of the initial
   authentication method; a peer receiving such Requests MUST treat them
   as invalid, and silently discard them.  As a result, Identity Requery
   is not supported.
"

Regards,

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 15 Jul 2004 16:21:02 -0700

OK, I understand.

I went back to your original proposed text. It is free of state
machine-like discussions (which is good, imo). Do you want to stick with
it, or are there any updates needed based on our discussion? 

> Here is a proposed solution for the lost answer problem.

Maybe "Responding to Duplicate Requests" is more representative as the
origin of duplication is on the Request side. 

> answered (as well as a fresh answer to a new request if any).  In

", the responder MAY send a duplicate answer to a request that it had
just answered."

> any).  

I'm not sure how these details relate to the discussion. If the
objective is to determine when the two requests are duplicate, maybe we
could say:

"The only difference between two consecutive duplicate requests
are the sequence numbers and the content of MAC AVP (when present)." 

> Retransmission of a duplicate answer in response to a duplicate

Shouldn't this be a "SHOULD"? I think this is safer towards more
robustness.

> PANA-Auth-Request message for the second EAP authentication.

I'd say "SHOULD" again.
 
> PANA-Bind-Answer message.

SHOULD again.

> messages may be a configurable parameter.

I think we can use the guidelines in Section 7.

So, we can say:

o When a PaC or a PAA receives a duplicate PANA-Termination-Request
  message for which it has already answered, it MAY send a duplicate
  PANA-Termination-Answer message in accordance with the timers
  Described in Section 7.

Even if we leave this as MAY, things would work as the requester would
eventually timeout.

Alper

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Yoshihiro Ohba
> Sent: Thursday, July 15, 2004 2:57 PM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; [email-masked]
> Subject: Re: [Pana] New: [issue98] Lost answer problem
> 
> > > > how the session moves from one state to another, and how
messages

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Jul 2004 21:31:16 -0400

In addition to the original proposed text, I's suggest adding the list
of unexpected requests.  Here is the entire proposed text:

[1] Change section 4.1.7:

"

to:

   Specifically the following messages are unexpected and invalid:

   o In discovery and initial handshake phase:

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

     - PANA-Bind-Request.

     - PANA-Update-Request.

   o In authentication phase:

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

     - PANA-Update-Request.

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

   o After successful PANA authentication:

     - PANA-Start-Request as well as a non-duplicate PANA-Bind-Request
       (see section 4.X for definition of duplicate requests)

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

   o In termination phase:

     - All requests but PANA-Termination-Request.
"

(I guess this section should move back, because it contains details.)

[2] Add the following section:

"   
Section 4.X  Responding to Duplicate Requests

Since PANA is designed over UDP, an answer as well as a request can be
lost.  In order to provide robustness against possible loss of
synchronization between a PaC and a PAA, the responder MAY send a
duplicate answer to a request that it had just answered.  The only
difference between two consecutive duplicate requests are the sequence
numbers and the content of MAC AVP (when present).

o When a PaC receives a duplicate PANA-Start-Request message for which
  it has already answered, it SHOULD send a duplicate
  PANA-Start-Answer message until it receives a valid
  PANA-Auth-Request message.

o When a PaC receives a duplicate PANA-FirstAuth-End-Request message
  for which it has already answered, it SHOULD send a duplicate
  PANA-FirstAuth-End-Answer message until it receives a valid
  PANA-Auth-Request message for the second EAP authentication.

o When a PaC receives a duplicate PANA-Bind-Request message for which
  it has already answered, it SHOULD send a duplicate PANA-Bind-Answer
  message until it receives some hint provided outside the PANA
  protocol (e.g., receipt of a secure association protocol message
  from an EP or receipt of data traffic) indicating that the PAA has
  received a PANA-Bind-Answer message.

  described in Section 7.
"

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 16 Jul 2004 11:03:03 -0700

Looks good to me.

Alper

> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Thursday, July 15, 2004 6:31 PM
> To: Alper Yegin
protocol
> > >    Request, an authenticator MUST NOT send a Request of a
different
> > Type
> > >    exception of a Notification-Request) and MUST NOT send a
Request
> > for
> > >    authentication method; a peer receiving such Requests MUST
treat
> > them
> > > > > > belongs to the state machine I-D. It can discuss definition
of
> > > > states,
> > > > > > processed in each state (ignored, rejected, causes state
change,
> > > > etc.)
> > > > > >    When a PANA message is received, the message is
considered to
> > be
> > > > > >    invalid at least when one of the following conditions are
not
> > > > met:
> > > > > pana-pana draft needs to specify what messages types are
expected
> > in
> > > > I went over your list of what is rejected (ignored?) in what
state.
> > They
> > > > looked intuitive to me, I mean things we don't need to spell
out.
> > Like
> > > > > Note that the suggested approach is different from the
approach
> > taken
> > > > > everything including which message should be accepted or
rejected
> > in
> > > > the PANA spec. An example text on PANA (for one message only)
would
> > be

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jul 2004 19:21:35 -0400

I realized that PANA-PAA-Discover message should not be expected in
authentication phase and termination phase.  I'd further revise [1] to
reflect this.

Yoshihiro Ohba