Subject: Re: [Pana] PANA relay implementation status

From: Jari Arkko <[email-masked]>
Date: Wed, 25 May 2011 13:12:54 +0200

I have reviewed this specification and sent it forward for IETF Last
Call. I think the spec is in good shape. There are a couple of issues
below, however, and I hope that you can resolve them in some
satisfactory manner. I have decided to forward the draft for IETF last
call anyway.

> The PaC-Information AVP contains the PaC's IP address
>    and UDP port number. 

... IP address and UDP source port number used for sending the PANA
messages.

>    (b) The IP address and the port number contained in the PaC-
>    Information AVP are maintained in the PANA session attribute "IP
>    address and UDP port number of the PaC".
>   

Please make it clearer that you are talking about a conceptual data
structure at the PAA, not a new PANA protocol attribute on the wire.

>    When the PAA originates a PANA message for a relayed PANA session, it
>    sends a PRY message to the PRE's IP address and UDP port number.

... IP address and sets the destination UDP port number to the source
UDP port number used in the PRE message.

> The PAA-
> originated PANA message is sent to the PaC's IP address and UDP port
> number.
>   

As above. You might also consider adding text about reversing the port
numbers, i.e., that the message that you are sending comes from the
source port that the request was sent to.

> 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.

> The Relayed-Message (AVP Code 11) is of type OctetString and contains
> a relayed PANA message.
>   

Without the IP/UDP encapsulation, I assume?

Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 26 May 2011 10:10:01 +0900

Hi Jari,

Thank you very much for reviewing the draft and moving forward it to
the IETF LC.  I think all issues except for the one that may lead to
defining a new Result-Code are straightforward.

Please see my comments below.

> ... IP address and UDP source port number used for sending the PANA

Yes, we will revise the text accordingly.

> structure at the PAA, not a new PANA protocol attribute on the wire.

We will revise the text to make this point clearer.

> UDP port number used in the PRE message.

Yes, that is better.  We will revise the text accordingly.

> source port that the request was sent to.

Yes, we will revise the text accordingly.

> relevant PANA message and set Result-Code to<TBD = Relay cannot route

Let me give some time to analyze the impact of this recommendation.

> Without the IP/UDP encapsulation, I assume?

Yes, without the IP/UDP encapsulation.  We will make this clearly stated.

Best Regards,
Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Thu, 26 May 2011 07:58:51 +0300

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 30 May 2011 13:07:37 +0900

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 30 May 2011 09:48:10 +0300

That would work for me.

Jari

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 30 May 2011 11:52:12 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jari Arkko
> Sent: Monday, May 30, 2011 9:48 AM
> To: Yoshihiro Ohba
> Cc: Ralph Droms; [email-masked]
> Subject: Re: [Pana] Explicit error indication
> 
> That would work for me.
> 
> Jari
> 
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pana

---

From: Jari Arkko <[email-masked]>
Date: Mon, 30 May 2011 12:12:35 +0300

I'm fine with using existing messages as well. In fact, that would 
probably be better.

Jari

Alper Yegin kirjoitti:
>>> to add such a feature if there is little impact to RFC 5191 to
>>>       
>> support
>>     
>>> carrying sequence number of zero (0) may be simple, something like
>>>       
>> this:
>>     
>>> PaC     PRE
>>>     --->     PCI
>>>> Ok. I' not claiming that my solution is necessarily the way forward,
>>>>         
>> but
>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 31 May 2011 23:21:46 +0900

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