Re: [Pana] Explicit error indication

Yoshihiro Ohba <> Wed, 01 June 2011 10:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 133CFE0780 for <>; Wed, 1 Jun 2011 03:11:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.674
X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jb+OY2-nvI6M for <>; Wed, 1 Jun 2011 03:11:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CD758E0764 for <>; Wed, 1 Jun 2011 03:11:06 -0700 (PDT)
Received: from ([]) by with ESMTP id p51AB3Ed012946; Wed, 1 Jun 2011 19:11:03 +0900 (JST)
Received: (from root@localhost) by id p51AB3M2007173; Wed, 1 Jun 2011 19:11:03 +0900 (JST)
Received: from unknown [] by with ESMTP id VAA07172; Wed, 1 Jun 2011 19:11:03 +0900
Received: from (localhost []) by with ESMTP id p51AB2sA020319; Wed, 1 Jun 2011 19:11:02 +0900 (JST)
Received: from by id p51AB2aG019681; Wed, 1 Jun 2011 19:11:02 +0900 (JST)
Received: from [] by (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <>; Wed, 01 Jun 2011 19:11:02 +0900 (JST)
Date: Wed, 01 Jun 2011 19:10:54 +0900
From: Yoshihiro Ohba <>
In-reply-to: <003f01cc2036$7fb5b780$7f212680$>
To: Alper Yegin <>
Message-id: <>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-2022-JP
Content-transfer-encoding: 7bit
References: <> <> <> <> <> <> <00a001cc1ea6$e40b4510$ac21cf30$> <> <003f01cc2036$7fb5b780$7f212680$>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv: Gecko/20110414 Thunderbird/3.1.10
Cc:, 'Ralph Droms' <>
Subject: Re: [Pana] Explicit error indication
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Jun 2011 10:11:08 -0000


If Jari is ok with your suggested text, there is no reason for me to
object it.

Yoshihiro Ohba

(2011/06/01 17:32), Alper Yegin wrote:
> Yoshi,
> I'm afraid my worries are coming true. I was worried that this would grow on
> us. Now we are talking about supporting different classes of error cases.
> Most probably we'd have to define bunch of error types. We'll try to be
> complete there. And then there are also case handling (e.g., whether session
> id is available, etc.). On top of that, defining general error messaging in
> this "extension" draft is not the right thing. That better have a separate
> base, if we decide to do such a work. One more thing: this impacts the PaC.
> Relaying did not have any impact on the PaC until that.
> On top of that, defining such error signaling is something we had debated
> long time in the base spec development and had agreed to remove. And again
> we had the same discussion in the context of PANA-relay, and then again
> decided to remove. Both after long debates and coming to conscious
> decisions. Such error messages are not useful for protocol operation, it is
> only good for debugging. As far as I know, we don't do these kind of error
> signaling in our IETF protocols. Silent discarding and optionally logging an
> error is what we do.
> I'm recapping Jari's email below. I'd like to go with his "I don't mind that
> we skip specifying this functionality now.", and take care of his "At the
> very least, we should
> specify what happens if you end up receiving an already relayed message." as
> follows:
> 	If the PRE is not configured with any PAA information, it SHALL
> silently discard the
> 	incoming PANA messages and it MAY log an error.
> 	If the PRE receives an PRY message from another PRE, then it SHOULD
> silently discard
> 	that message and it MAY log an error. Future extensions may define a
> multi-hop relay
> 	procedure which can change the PRE behavior in this respect.
> What do you think?
> Alper
> ------- Jari's email ----------------
>> This specification assumes there is at most one PRE between the PaC
>> and the PAA.  Performing relay operation on a PANA message that is
>> already relayed (i.e., carried inside a PRY message) is out-of scope
>> of this specification.
> This is problematic, as it may occur. At the very least, we should
> specify what happens if you end up receiving an already relayed message.
> Loops may also occur.
> I don't mind that we skip specifying this functionality now. What I'm
> worried about is the upgrade to doing something better in the future. If
> we don't do something now, how do we know tomorrow that our messages are
> being correctly relayed?
> I would recommend the following behaviour, actually. If the relay
> detects an already existing relay attributes or has no configuration to
> actually be able to send something to a PAA, it would reply with the
> relevant PANA message and set Result-Code to<TBD = Relay cannot route
> message>. This would allow the client to at least know something is
> wrong. This would also allow the relay to signal other erroneous
> conditions to the client.
> -----------------------------
>> -----Original Message-----
>> From: Yoshihiro Ohba []
>> Sent: Tuesday, May 31, 2011 5:22 PM
>> To: Alper Yegin
>> Cc: 'Jari Arkko'; 'Ralph Droms';
>> Subject: Re: [Pana] Explicit error indication
>> Hi Alper,
>> In the first part of your email, PRE-to-PRE error indication is
>> mentioned.  I only considered PRE-to-PaC error indication in my
>> previous email, but I think we can support PRE-to-PRE error indication
>> as well.  I think both PRY with an error indication AVP and a new
>> error indication message can be workable here, but
>> a Result-Code AVP may not be appropriate for temporal errors (see
>> below) because the use of a Result-Code AVP is to indicate whether EAP
>> authentication was completed successfully.
>> For PRE-to-PaC error indication, I thought that using a
>> Result-Code for that purpose has an impact on existing RFC 5191
>> implementations that do not expect to receive a Result-Code in the
>> first PAR with the 'S' bit set, because in the current use of a
>> Result-Code is for the last PAR message with the 'C' bit set, but RFC
>> 5191 explicitly prohibits to set both the 'S' bit and 'C' bit at the
>> same time.  So I thought defining a new message (just as we define
>> PRY) has less impact on RFC 5191 as an implementation that does not
>> support the new message will simply discard the message and the
>> initial PAR-PAN exchange part is kept intact.  Maybe I am missing
>> something.  If a Result-Code in the initial PAR works without
>> impacting on RFC 5191, then I am also ok with it.
>> Regarding types of error, some error can be temporary.  For example,
>> temporal buffer shortage or temporal routing fluctuations (e.g., even
>> if the PRE has the  PAA information there may be no next hop towards
>> the PAA), both can be recoverable (so a PaC may retry PANA
>> authentication later on).  I think it would be good we can
>> support both non-temporal and temporal errors as long as the impact on
>> RFC 5191 is low.
>> Regarding which session identifier should be used for a new message
>> for error indication, I think the session id contained in the message
>> that caused the error should be used.  When the error indication
>> message is sent in response to PCI or PRY, then session id is zero,
>> otherwise non-zero.
>> Regards,
>> Yoshihiro Ohba
>> (2011/05/30 17:52), Alper Yegin wrote:
>>> For relaying already relayed messages... The Result-Code AVP
>> (something like
>>> MULTIPLE-RELAYING-DISALLOWED) would be included in the PRY message
>> sent from
>>> one PRE to the other.
>>> In response to a PRY that was received from the latter one.
>>> How seq no and PANA SA are used for PRY is already defined. There'd
>> not be
>>> any special considerations here.
>>> Right?
>>> The other Result-Code would be something like RELAY-REJECTED-NO-PAA-
>> INFO.
>>> This can be carried in a PAR in response to the PCI received from the
>> PaC.
>>> (Defining it in response to any other message is less justified [why
>> would
>>> PER lose the PAA info in the middle of a session relaying?], and also
>> less
>>> trivial [what would the session id be set to??]
>>> I'm trying to see if we can achieve this with the minimum impact.
>>> I don't think we need a new message. We just need new Result-Codes.
>>> We shouldn't have to touch RFC 5191.
>>> Alper
>>>> -----Original Message-----
>>>> From: [] On Behalf
>> Of
>>>> Jari Arkko
>>>> Sent: Monday, May 30, 2011 9:48 AM
>>>> To: Yoshihiro Ohba
>>>> Cc: Ralph Droms;
>>>> Subject: Re: [Pana] Explicit error indication
>>>> That would work for me.
>>>> Jari
>>>> Yoshihiro Ohba kirjoitti:
>>>>> Let me start a new thread on this subject.
>>>>> I remember a ZigBee member asked if explicit error indication can
>> be
>>>>> sent by a PRE when a PANA message cannot be relayed for some
>> reasons
>>>>> (buffer shortage, no route to PAA, etc.).  I think it would be
>> useful
>>>>> to add such a feature if there is little impact to RFC 5191 to
>>>> support
>>>>> the feature, as it could reduce unnecessarily retransmissions of
>> PCIs
>>>>> from PaCs.  Reduce unnecessarily retransmissions may be good for
>>>>> resource constrained networks such as ZigBee.
>>>>> Explicit error indication can be by means of a new PANA message or
>> a
>>>>> new Result-Code.
>>>>> Processing explicit error indication is like handling
>>>>> exceptions/interruptions.  So considerations would be necessarily
>>>>> not to interfere with the PANA sequence number processing rule.
>>>>> Especially this would be the case where an error indication is
>>>>> protected by a PANA SA.  I would expect that we don't need to
>> support
>>>>> protected error indication as it would require a complex sequence
>>>>> number processing rule such as a separate sequence number space
>>>>> dedicated to error indications.
>>>>> IMHO, a new PANA message (e.g., PANA-Error-Indication)
>>>>> carrying sequence number of zero (0) may be simple, something like
>>>> this:
>>>>> PaC     PRE
>>>>>       --->       PCI
>>>>>       <---     PEI[Error-Code="Relay-failed"] // seqno=0
>>>>> PEI message is unprotected and it can be used only as a hint.
>>>>> Regards,
>>>>> Yoshihiro Ohba
>>>>> (2011/05/26 13:58), Jari Arkko wrote:
>>>>>> Yoshihiro,
>>>>>>> Let me give some time to analyze the impact of this
>> recommendation.
>>>>>> Ok. I' not claiming that my solution is necessarily the way
>> forward,
>>>> but
>>>>>> I am worried about the issue.
>>>>>> Jari
>>>> _______________________________________________
>>>> Pana mailing list