[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