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

Robert Cragie <> Wed, 15 December 2010 08:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C42E43A6F61; Wed, 15 Dec 2010 00:21:27 -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 iqjlLh3Ov3xe; Wed, 15 Dec 2010 00:21:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 653BA3A6E46; Wed, 15 Dec 2010 00:21:24 -0800 (PST)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PSmdN-0002KP-Is; Wed, 15 Dec 2010 08:22:50 +0000
Message-ID: <>
Date: Wed, 15 Dec 2010 08:22:45 +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="------------ms010002030800010202000003"
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: Wed, 15 Dec 2010 08:21:27 -0000


Thanks for your response. Some further comments below, bracketed by 

In summary, I think there are two security considerations in addition to 
the other text already proposed which need to be addressed:

   1. The PRE, as a protocol-aware relay, MUST only relay PRY messages
      and MUST only accept valid PANA messages
   2. The use of a PRE causes additional state at the PAA (IP address
      and port of PRE) which may need to be stored

Whilst the language Alper has used so far is probably sufficient, I do 
think that it is important to strenuously recommended that the PRE-PAA 
connection is secured using either DTLS, PANA SA or L2 protection;


Robert Cragie (Pacific Gas & Electric)

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

On 14/12/2010 8:16 PM, Alan DeKok wrote:
> Robert Cragie wrote:
>>      * 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.
>    Thanks.
>>      * 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.
>    It would *authenticate* the data sent from the PAA to the PRE.  This
> authentication would ensure that the PAA could only respond to packets
> sent by the PRE.
<RCC>Unless I am missing something, a token generated and validated by 
the PRE could only authenticate the immutable parts of the PRY, i.e. the 
PaC-Information AVP. You would need a full security association between 
PRE and PAA to authenticate different messages in both directions.</RCC>
>    As I said earlier, this would ensure that a rogue PAA can only (a)
> send PANA messages, to (b) the IP of the PaC, and (c) the port of the
> PaC used to send PANA messages.  It would prevent a rogue PAA from
> sending a non-PANA frame to arbitrary non-PANA IPs and ports.
<RCC>The use of a token doesn't enforce (a) but the PRE can check for 
(a) in the scope of PANA as a transport. I agree it does enforce (b) and 
(c). The question is whether the additional effort is worth it on the 
basis that considering a PaC-PAA communication, the IP address and port 
may not be protected either and PANA doesn't require it at the moment.</RCC>
>>   Using DTLS between PRE and PAA would
>>        provide protection for the whole packet, possibly including
>>        encryption.
>     It's not per-packet protection.  It's that the PRE will only accept
> frames from the PAA that have been authenticated via TLS.
<RCC>Agreed - that's essentially what I meant; perhaps I used the wrong 
>> 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
>    The document clearly states that the PRE is proxying packets because
> the PAA can not otherwise route traffic to the PaC.  Security between
> the PAA and PRE is *required* to prevent rogue PAAs from causing the PRE
> to route traffic to the PaC.
<RCC>I agree it is required to prevent rogue PAAs from causing the PRE 
to route traffic. It would seem the debate is about whether we have to 
mandate this for PRE-PAA in general as PANA, as a transport, does not 
require it.</RCC>
>    One view could be that the PaC is already vulnerable to rogue PAAs on
> the local network.  That local network may, however, be limited in the
> number of systems, and what they're allowed to do.  My presumption is
> that the PRE to PAA network is a fully-connected network capable of
> routing to arbitrary destinations.
>    So adding a PRE opens the PaC to attacks from arbitrary sources on a
> wide-area network, which would seem to be a violation of the PANA
> assumptions.
<RCC>That is true. However, I think Alper's point is that an equivalent 
MiTM router on a wider network in the vicinity of the PaC could still be 
the target for a rogue PAA and that the PRE model was really no 
different. So this doesn't necessarily pose an *additional* threat.</RCC>
>    Alan DeKok.