Re: [Pana] PANA relay implementation status

Jari Arkko <jari.arkko@piuha.net> Wed, 25 May 2011 11:12 UTC

Return-Path: <jari.arkko@piuha.net>
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 D0FCAE0680 for <pana@ietfa.amsl.com>; Wed, 25 May 2011 04:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level:
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 bEG72DGsXQDu for <pana@ietfa.amsl.com>; Wed, 25 May 2011 04:12:57 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id BA616E0697 for <pana@ietf.org>; Wed, 25 May 2011 04:12:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5F6342CC3B; Wed, 25 May 2011 14:12:55 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Sb8X-CJaQNH; Wed, 25 May 2011 14:12:54 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CB75F2CC2F; Wed, 25 May 2011 14:12:54 +0300 (EEST)
Message-ID: <4DDCE436.2010507@piuha.net>
Date: Wed, 25 May 2011 13:12:54 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
References: <4D5AA4A7.3050104@toshiba.co.jp>
In-Reply-To: <4D5AA4A7.3050104@toshiba.co.jp>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: Ralph Droms <rdroms@cisco.com>, pana@ietf.org
Subject: Re: [Pana] PANA relay implementation status
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, 25 May 2011 11:12:58 -0000

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