Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay)

Robert Cragie <> Tue, 14 December 2010 17:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 023753A6F9B; Tue, 14 Dec 2010 09:23:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5TASmqU9lJpX; Tue, 14 Dec 2010 09:23:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1449E3A6EB8; Tue, 14 Dec 2010 09:23:48 -0800 (PST)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PSYci-0002XM-Lv; Tue, 14 Dec 2010 17:25:13 +0000
Message-ID: <>
Date: Tue, 14 Dec 2010 17:25:08 +0000
From: Robert Cragie <>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv: Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Alan DeKok <>
References: <> <> <001101cb9aa0$367b3480$a3719d80$> <>
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms000407040602030407080206"
X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:03 -0800
Cc: 'Yoshihiro Ohba' <>,,, Alper Yegin <>,,,,, 'Ralph Droms' <>
Subject: Re: [secdir] Token (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: Tue, 14 Dec 2010 17:23:50 -0000


Thank you for your review of the PANA relay draft. Sorry for the late 
reply - I was busy last week (actually testing PANA relay). In response 
to some of your points:

    * I agree with the notion of enforcing the relay to only process
      valid PANA messages and only send valid PANA messages. The fact it
      is a functionally-defined relay (as opposed to a generic IP
      tunnel) means that we can do this. Therefore we need to add text
      as you suggest.
    * I am less sure of the need for a token. As far as I can see, the
      token would only protect the immutable information in the data
      sent from PRE to PAA, i.e. the IP address and the port. This has
      some benefit but would not necessarily prevent a rogue PAA sending
      a bogus encapsulated frame. Using DTLS between PRE and PAA would
      provide protection for the whole packet, possibly including
      encryption. Using a PANA SA would provide better protection than a
      PRE-originated token. Using L2 security also provides a 'walled
      garden' protection. It seems to me possible for a rogue node to
      send any packet to any port on a node which is accessible at the
      link layer provided one knows its address and assumes no L2
      security therefore I don't again see this as an additional threat


Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064 <>

On 13/12/2010 4:14 PM, Alan DeKok wrote:
> Alper Yegin wrote:
>> Arbitrary traffic cannot pass the validation on the PaC, as the sequence
>> numbers need to match. And there is also state machine match needed. PaC's
>> is in certain state and would not react to any arbitrary message unless the
>> message is expected in the current state.
>    If the traffic is sent to the PANA port used by the PaC.  The traffic
> *can* be sent to other ports.  As it stands today, the draft doesn't
> appear to prevent this.
>    The idea of the token is to add limited state to the PRE.  It will
> only send messages that are (a) valid PANA messages, (b) to the IP of a
> PaC, and (c) to the port used by the PaC used to send PANA messages.
>    Using DTLS in between the PRE and PAA would achieve the same effect.
> The possibility of a rogue PAA is removed, so no token is required.
>    Alan DeKok.