Re: [Pana] Explicit error indication

Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp> Wed, 01 June 2011 10:11 UTC

Return-Path: <yoshihiro.ohba@toshiba.co.jp>
X-Original-To: pana@ietfa.amsl.com
Delivered-To: pana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133CFE0780 for <pana@ietfa.amsl.com>; Wed, 1 Jun 2011 03:11:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.674
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb+OY2-nvI6M for <pana@ietfa.amsl.com>; Wed, 1 Jun 2011 03:11:07 -0700 (PDT)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id CD758E0764 for <pana@ietf.org>; Wed, 1 Jun 2011 03:11:06 -0700 (PDT)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p51AB3Ed012946; Wed, 1 Jun 2011 19:11:03 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id p51AB3M2007173; Wed, 1 Jun 2011 19:11:03 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id VAA07172; Wed, 1 Jun 2011 19:11:03 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p51AB2sA020319; Wed, 1 Jun 2011 19:11:02 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p51AB2aG019681; Wed, 1 Jun 2011 19:11:02 +0900 (JST)
Received: from [133.196.17.34] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LM300K09WAEXDD0@mail.po.toshiba.co.jp>; Wed, 01 Jun 2011 19:11:02 +0900 (JST)
Date: Wed, 01 Jun 2011 19:10:54 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <003f01cc2036$7fb5b780$7f212680$%yegin@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
Message-id: <4DE6102E.7040703@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-2022-JP
Content-transfer-encoding: 7bit
References: <4D5AA4A7.3050104@toshiba.co.jp> <4DDCE436.2010507@piuha.net> <4DDDA869.204@toshiba.co.jp> <4DDDDE0B.4070601@piuha.net> <4DE31809.1040100@toshiba.co.jp> <4DE33DAA.9060307@piuha.net> <00a001cc1ea6$e40b4510$ac21cf30$%yegin@yegin.org> <4DE4F97A.1040406@toshiba.co.jp> <003f01cc2036$7fb5b780$7f212680$%yegin@yegin.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
Cc: pana@ietf.org, 'Ralph Droms' <rdroms@cisco.com>
Subject: Re: [Pana] Explicit error indication
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pana>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2011 10:11:08 -0000

Alper,

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

Regards,
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 [mailto:yoshihiro.ohba@toshiba.co.jp]
>> Sent: Tuesday, May 31, 2011 5:22 PM
>> To: Alper Yegin
>> Cc: 'Jari Arkko'; 'Ralph Droms'; pana@ietf.org
>> 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: pana-bounces@ietf.org [mailto:pana-bounces@ietf.org] On Behalf
>> Of
>>>> Jari Arkko
>>>> Sent: Monday, May 30, 2011 9:48 AM
>>>> To: Yoshihiro Ohba
>>>> Cc: Ralph Droms; pana@ietf.org
>>>> 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
>>>> Pana@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pana
>>>
>>>
> 
>