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

Alan DeKok <> Mon, 13 December 2010 16:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A002928C0E2; Mon, 13 Dec 2010 08:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.576
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RKBOd9AqeYMX; Mon, 13 Dec 2010 08:10:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BE8793A6DDA; Mon, 13 Dec 2010 08:10:10 -0800 (PST)
Message-ID: <>
Date: Mon, 13 Dec 2010 17:11:47 +0100
From: Alan DeKok <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: Alper Yegin <>
References: <> <> <001001cb9a9f$b697a460$23c6ed20$>
In-Reply-To: <001001cb9a9f$b697a460$23c6ed20$>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 'Yoshihiro Ohba' <>,,,,,,,, 'Ralph Droms' <>
Subject: Re: [secdir] PRE enforcing message validity (was RE: Secdir review of draft-ohba-pana-relay)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.