IETF Logo Mail Archive

Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay)

Alan DeKok <aland@deployingradius.com> Wed, 15 December 2010 14:25 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3DD28C0E5; Wed, 15 Dec 2010 06:25:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.586
X-Spam-Level:
X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, 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 ZY1MqumpRgLs; Wed, 15 Dec 2010 06:25:56 -0800 (PST)
Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 680EF28C0DD; Wed, 15 Dec 2010 06:25:56 -0800 (PST)
Message-ID: <4D08D059.1090106@deployingradius.com>
Date: Wed, 15 Dec 2010 15:27:37 +0100
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: robert.cragie@gridmerge.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> <4D087AD5.8020901@gridmerge.com> <4D089C73.6050107@deployingradius.com> <4D08CF2A.9080909@gridmerge.com>
In-Reply-To: <4D08CF2A.9080909@gridmerge.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 'Yoshihiro Ohba' <yoshihiro.ohba@toshiba.co.jp>, secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, Alper Yegin <alper.yegin@yegin.org>, margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, samitac@ipinfusion.com, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Dec 2010 14:25:58 -0000

Robert Cragie wrote:
> Actually, there is one additional consideration - the PRE has to have
> prior knowledge of the PAA address. It is not stated how this is
> achieved but is state which is stored in the PRE which means not just
> any rogue device can masquerade as the PAA as the PRE would check the
> source address. A rogue PAA would either have to hijack the PRE-PAA
> address resolution phase or somehow obtain the PAA address and spoof it.

  PANA is carried over UDP, right?

  Anyone can trivially spoof UDP packets.  Checking the PAA source IP is
useful, but it adds no security.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email