[Pana] FW: PRE enforcing message validity (was RE: Secdir review of draft-ohba-pana-relay)
"Alper Yegin" <alper.yegin@yegin.org> Tue, 14 December 2010 08:38 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 B6B4E3A6E59 for <pana@core3.amsl.com>; Tue, 14 Dec 2010 00:38:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.717
X-Spam-Level:
X-Spam-Status: No, score=-100.717 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, 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 lri-iZa0iP7i for <pana@core3.amsl.com>; Tue, 14 Dec 2010 00:38:57 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id DCD923A6D5C for <pana@ietf.org>; Tue, 14 Dec 2010 00:38:56 -0800 (PST)
Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M1FVw-1QLcSH2NMe-00t6yW; Tue, 14 Dec 2010 03:40:35 -0500
From: Alper Yegin <alper.yegin@yegin.org>
To: pana@ietf.org
Date: Tue, 14 Dec 2010 10:40:30 +0200
Message-ID: <002d01cb9b6a$93c3ea40$bb4bbec0$@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: AcuYPqjxXV+rcKfeSK63xsDrVdaSlACYEgOgADLmH+A=
Content-Language: en-us
X-Provags-ID: V02:K0:XXN3umfCIHxsexhYCJQf2V0OFXRCpdvAiK47FMkcEr3 6BfLza+ACytD1eob2TK3M5C2C+/d/+bxLHqoh1h/R/eBl66wtn PXh4uHESLYhRQzLz9hHSpihFbDisGJeFDVeaakQg6xG3gi8T1n pyHUv4ZUuzGqK4EZIdRFkWmiwvKsAPWWx7B/CmWEPeZEAxGoAQ LDK+uDdoO1OUeku4OS78ryfRx3vk9igIZ8PYdtrCE0=
Subject: [Pana] FW: PRE enforcing message validity (was RE: Secdir review of draft-ohba-pana-relay)
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: Tue, 14 Dec 2010 08:38:57 -0000
Resending to the list..... -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Monday, December 13, 2010 10:28 AM To: 'Yoshihiro Ohba'; 'Alan DeKok' Cc: 'secdir@ietf.org'; 'draft-ohba-pana-relay@tools.ietf.org'; 'margaretw42@gmail.com'; 'Ralph Droms'; 'paduffy@cisco.com'; 'samitac@ipinfusion.com'; 'robert.cragie@gridmerge.com'; 'pana@ietf.org' Subject: PRE enforcing message validity (was RE: Secdir review of draft-ohba-pana-relay) Hi Alan, Thank you for the review. > > The Security Considerations section says: > > > > Since the PRE does not maintain per-PaC state, the PRE is robust > > against resource consumption DoS (Deniable of Service) attack. > > > > However, the PRE relays packets to the PaC. This means that > entities > > on the PAA network can now send PANA messages to the PaC, when they > > previously could not. 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? > > > > The same attack applies (but less so) in the inverse direction. A > > fake PaC can send the PAA arbitrary PANA messages. Since this can > > already happen today, there is no new issue here. > > > > Having a stateful PRE would help address this attack. It would > not > > prevent it, as the PANA messages are unsigned, and anyone can pretend > to > > be the PRE. > > > > I would suggest requiring that the PRE enforce the Message > Validity > > checks of RFC 5191, Section 5.5. If this cannot be done in its > > entirety, this draft should add a new section entitled "Message > Validty > > checks for the PRE". > > > > 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. Alper