Re: [secdir] PRE enforcing message validity (was RE: Secdir review of draft-ohba-pana-relay)
Alan DeKok <aland@deployingradius.com> Mon, 13 December 2010 16:10 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 A002928C0E2; Mon, 13 Dec 2010 08:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level:
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 RKBOd9AqeYMX; Mon, 13 Dec 2010 08:10:10 -0800 (PST)
Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id BE8793A6DDA; Mon, 13 Dec 2010 08:10:10 -0800 (PST)
Message-ID: <4D0645C3.7060406@deployingradius.com>
Date: Mon, 13 Dec 2010 17:11:47 +0100
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Alper Yegin <alper.yegin@yegin.org>
References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001001cb9a9f$b697a460$23c6ed20$@yegin@yegin.org>
In-Reply-To: <001001cb9a9f$b697a460$23c6ed20$@yegin@yegin.org>
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, margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, robert.cragie@gridmerge.com, samitac@ipinfusion.com, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: Re: [secdir] PRE enforcing message validity (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: Mon, 13 Dec 2010 16:10:11 -0000
Alper Yegin wrote: >>> While the PaC is supposed to discard invalid >>> and/or unexpected messages (RFC 5191), the PRE can be used to send >>> messages to *arbitrary* UDP ports on the PaC or any other machine in >> the >>> PaC network. > > Is the concern that a rogue PRE injecting bogus PANA messages towards the > PaC, or a legitimate PRE relaying bogus PANA messages injected by some rogue > PAA? A legitimate PRE relaying bogus PANA messages. Or even non-PANA messages. From my reading of the draft, the reply from the PAA is a PANA message with a PANA message carried as a TLV. But there is *no* requirement that the TLV actually carries a real PANA message. So it can be anything. >>> e.g. The PRE MUST relays only well-formed PANA messages to the >> PAA. >>> And before relaying messages back to the PaC, it ensures that the >>> Relayed-Message AVP contains a well-formed PANA message. All >> malformed >>> messages MUST be discarded. > > Why not let the PaC deal with this? It already performs such checks. The PaC discards invalid PANA messages sent to the port from which it sent PANA messages. Since the PRE is stateless, it can be coerced into sending messages to *any* port on the PaC. Since the PRE has no requirement to verify the relayed message, it doesn't even have to be PANA. The PRE can be convinced to relay arbitrary data to arbitrary UDP ports on the PaC. This can't be a good thing. 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