Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay)
Robert Cragie <robert.cragie@gridmerge.com> Tue, 14 December 2010 17:23 UTC
Return-Path: <robert.cragie@gridmerge.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 023753A6F9B; Tue, 14 Dec 2010 09:23:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 5TASmqU9lJpX; Tue, 14 Dec 2010 09:23:48 -0800 (PST)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 1449E3A6EB8; Tue, 14 Dec 2010 09:23:48 -0800 (PST)
Received: from client-86-31-167-78.oxfd.adsl.virginmedia.com ([86.31.167.78] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PSYci-0002XM-Lv; Tue, 14 Dec 2010 17:25:13 +0000
Message-ID: <4D07A874.4010702@gridmerge.com>
Date: Tue, 14 Dec 2010 17:25:08 +0000
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
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>
In-Reply-To: <4D064683.30009@deployingradius.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms000407040602030407080206"
X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:03 -0800
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
Reply-To: robert.cragie@gridmerge.com
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: Tue, 14 Dec 2010 17:23:50 -0000
Alan, Thank you for your review of the PANA relay draft. Sorry for the late reply - I was busy last week (actually testing PANA relay). In response to some of your points: * I agree with the notion of enforcing the relay to only process valid PANA messages and only send valid PANA messages. The fact it is a functionally-defined relay (as opposed to a generic IP tunnel) means that we can do this. Therefore we need to add text as you suggest. * I am less sure of the need for a token. As far as I can see, the token would only protect the immutable information in the data sent from PRE to PAA, i.e. the IP address and the port. This has some benefit but would not necessarily prevent a rogue PAA sending a bogus encapsulated frame. Using DTLS between PRE and PAA would provide protection for the whole packet, possibly including encryption. Using a PANA SA would provide better protection than a PRE-originated token. Using L2 security also provides a 'walled garden' protection. It seems to me possible for a rogue node to send any packet to any port on a node which is accessible at the link layer provided one knows its address and assumes no L2 security therefore I don't again see this as an additional threat Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com <http://www.gridmerge.com/> On 13/12/2010 4:14 PM, Alan DeKok wrote: > Alper Yegin wrote: >> Arbitrary traffic cannot pass the validation on the PaC, as the sequence >> numbers need to match. And there is also state machine match needed. PaC's >> is in certain state and would not react to any arbitrary message unless the >> message is expected in the current state. > If the traffic is sent to the PANA port used by the PaC. The traffic > *can* be sent to other ports. As it stands today, the draft doesn't > appear to prevent this. > > The idea of the token is to add limited state to the PRE. It will > only send messages that are (a) valid PANA messages, (b) to the IP of a > PaC, and (c) to the port used by the PaC used to send PANA messages. > > Using DTLS in between the PRE and PAA would achieve the same effect. > The possibility of a rogue PAA is removed, so no token is required. > > Alan DeKok. >
- [secdir] Secdir review of draft-ohba-pana-relay Alan DeKok
- Re: [secdir] Secdir review of draft-ohba-pana-rel… Yoshihiro Ohba
- Re: [secdir] Secdir review of draft-ohba-pana-rel… Alan DeKok
- [secdir] PRE enforcing message validity (was RE: … Alper Yegin
- [secdir] Token (was RE: Secdir review of draft-oh… Alper Yegin
- Re: [secdir] PRE enforcing message validity (was … Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Robert Cragie
- Re: [secdir] Token (was RE: Secdir review of draf… Robert Cragie
- Re: [secdir] Token (was RE: Secdir review of draf… Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Alan DeKok
- Re: [secdir] Token (was RE: Secdir review of draf… Robert Cragie
- Re: [secdir] Token (was RE: Secdir review of draf… Robert Cragie
- [secdir] pana-relay security considerations Alper Yegin
- Re: [secdir] pana-relay security considerations Alan DeKok
- Re: [secdir] pana-relay security considerations Alper Yegin
- Re: [secdir] pana-relay security considerations Alan DeKok
- Re: [secdir] pana-relay security considerations Alper Yegin
- Re: [secdir] pana-relay security considerations Alan DeKok
- Re: [secdir] pana-relay security considerations Alan DeKok
- Re: [secdir] pana-relay security considerations Margaret Wasserman
- Re: [secdir] pana-relay security considerations Alper Yegin