[secdir] PRE enforcing message validity (was RE: Secdir review of draft-ohba-pana-relay)

"Alper Yegin" <alper.yegin@yegin.org> Mon, 13 December 2010 08:27 UTC

Return-Path: <alper.yegin@yegin.org>
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 DF2183A6CE7; Mon, 13 Dec 2010 00:27:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.85
X-Spam-Level:
X-Spam-Status: No, score=-99.85 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 JwArK6QBJUDi; Mon, 13 Dec 2010 00:27:08 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id E4AC23A6900; Mon, 13 Dec 2010 00:27:07 -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 0Mhi4R-1PoFTi0U7f-00N5LG; Mon, 13 Dec 2010 03:28:26 -0500
From: "Alper Yegin" <alper.yegin@yegin.org>
To: "'Yoshihiro Ohba'" <yoshihiro.ohba@toshiba.co.jp>, "'Alan DeKok'" <aland@deployingradius.com>
References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp>
In-Reply-To: <4D01DABF.6060604@toshiba.co.jp>
Date: Mon, 13 Dec 2010 10:28:10 +0200
Message-ID: <001001cb9a9f$b697a460$23c6ed20$@yegin@yegin.org>
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+rcKfeSK63xsDrVdaSlACYEgOg
Content-Language: en-us
X-Provags-ID: V02:K0:DS3Zt2Q9nWRGOeGpCSsrLF65VBjLLyIeU3yaz/kT8re j8wUbTKLaD37OX3FaoMylOXCApEtFJAmMxw3tH1uKhlB/aXeic O99Sf7Ykr/P1TPCj2Nxug9xknRBj9ukAMD/QQEvsIazh156YnZ 6rg7n7ClYpnmh+yk79XQ5XjFDXqTKKgZKfRtSmR8qhSqgxCPJg LV25riH5MaKMeezwa7xVwbwCihWV50PfZwtP7LIkqE=
Cc: 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: [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 08:27:09 -0000

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