Re: [Pana] pana-relay security considerations

"Alper Yegin" <alper.yegin@yegin.org> Mon, 10 January 2011 10:34 UTC

Return-Path: <alper.yegin@yegin.org>
X-Original-To: pana@core3.amsl.com
Delivered-To: pana@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BEC83A6956; Mon, 10 Jan 2011 02:34:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.561
X-Spam-Level:
X-Spam-Status: No, score=-100.561 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8m2pQ9JZoRr; Mon, 10 Jan 2011 02:34:40 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 9388B28C0ED; Mon, 10 Jan 2011 02:34:40 -0800 (PST)
Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M8lvA-1PSK0u2OK4-00CcFo; Mon, 10 Jan 2011 05:36:47 -0500
From: Alper Yegin <alper.yegin@yegin.org>
To: 'Alan DeKok' <aland@deployingradius.com>
References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> <4D07A874.4010702@gridmerge.com> <4D07D090.9020407@deployingradius.com> <070601cba3ad$63852150$2a8f63f0$@yegin@yegin.org> <4D270D1D.8090006@deployingradius.com>
In-Reply-To: <4D270D1D.8090006@deployingradius.com>
Date: Mon, 10 Jan 2011 12:35:46 +0200
Message-ID: <005f01cbb0b2$2bc21cc0$83465640$@yegin>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcuuahYO8CAV0E0sQci2eFTD0TST8wCRmpHQ
Content-Language: en-us
X-Provags-ID: V02:K0:Q8vWxxcFPRbIpR+Ghh197rTw+iHbMC7mQgL2bQoyt+Q hH81m72HDjhlxwAAM89IGS6YtMgOXOA4IStANmTB1IQRrRbeRb D+Xgo12gI26B1AlYJDhOtutplxfFiT7zxkzpn+dahtM3Fxu3mb e2I21e/1T1aiy6FVXQuUrSe/PhYOHqO/OiccBVGEE1xbyCR6r7 A5I1LZjtDSssMlT1MFW9qnLaSzg0CrD9rZALxEub0c=
Cc: secdir@ietf.org, pana@ietf.org, robert.cragie@gridmerge.com, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: Re: [Pana] pana-relay security considerations
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 10 Jan 2011 10:34:41 -0000

Hi Alan,


>   It looks good.  I'd like to know if the PRE can relay messages from
> the PAA to the PaC on a non-PANA port.  If so, that needs to be
> addressed somehow.  Saying "use DTLS" might not be enough.

The PaC picks an ephemeral port when sending the PANA packet. Src:any, dst:
716. And the response from the PAA reverses the ports. 

The most PRE can do is to check if source port is 716.

If the PRE knows that it received the packet from a trusted source (by means
of DTLS, physical security, IPsec, etc.), then the PRE should not
normally(*) have to perform another level of check on the packets. 

(*) If the PRE cares extra about this, it can start performing DPI on the
packets. I don't think we should specify this in the document though.

> 
>   If the PaC always sends packets from the PANA port, then the text
> should be updated to say that the PAA only sends packets to the PANA
> port on the PaC.

Alper






> 
>   Alan DeKok.