Re: [secdir] sector review of draft-ietf-pcp-server-selection-07

"Prashanth Patil (praspati)" <> Mon, 05 January 2015 07:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 68D491A1BEA; Sun, 4 Jan 2015 23:43:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2ugcm3nk9Ykd; Sun, 4 Jan 2015 23:43:06 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 72FC61A1BE4; Sun, 4 Jan 2015 23:43:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3477; q=dns/txt; s=iport; t=1420443786; x=1421653386; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=D5Z8u2ELuVaBQ7rxx0qJcYv7l6fBwWrWGB2YtANWxSo=; b=cZFhcB675nL3MkHi7/t1p/PoZk/7lAFTBEeuVs1RShqqq9zdTSUxZaLX jKCoxIyMiNpQT6mAjuiWu9sGj/VHkZ0ljq4x9suyUO5YQyBL4xe/P3YhS UPsprFYg2vBBCPPW7hunHFXhNiZbaUgS1sgWYRlONOMPmV2oYWW5YXpYB U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,698,1413244800"; d="scan'208";a="110311255"
Received: from ([]) by with ESMTP; 05 Jan 2015 07:43:05 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t057h45f007532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jan 2015 07:43:04 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 01:43:04 -0600
From: "Prashanth Patil (praspati)" <>
To: "" <>, "Chris Inacio" <>, "" <>, "" <>, "" <>
Thread-Topic: sector review of draft-ietf-pcp-server-selection-07
Thread-Index: AQHQKLs9yOlJryMOcUmiTJHGP8qETA==
Date: Mon, 5 Jan 2015 07:43:04 +0000
Message-ID: <>
References: <> <787AE7BB302AE849A7480A190F8B9330048DEF48@OPEXCLILM23.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330048DEF48@OPEXCLILM23.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 05 Jan 2015 02:10:24 -0800
Subject: Re: [secdir] sector review of draft-ietf-pcp-server-selection-07
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Jan 2015 07:43:08 -0000

Hi Med,
Given that this is a recommendation for efficiency, we could perhaps
change 'SHOULD' to a 'MAY'.

We only introduced this because it's easier on the client to use the same
mapping nonce when it tries to connect with each address of the same
server in a sequential manner.


On 1/5/15 1:04 PM, ""
<> wrote:

>Dear Chris,
>Thank you for the review.
>Nonce validation checks are used when operating in the simple threat
>model as discussed in RFC6887. Adding a reference to section 18.1 of
>RFC6887 would be sufficient IMHO. PCP authentication will be needed if
>operating in the Advanced Threat Model.
>For efficiency, the PCP client SHOULD use the same Mapping Nonce for
>requests sent to all IP addresses belonging to the same PCP server.
> For efficiency, the PCP client SHOULD use the same Mapping Nonce for
>requests sent to all IP addresses belonging to the same PCP server. As a
>reminder, nonce validation checks are performed when operating in the
>Simple Threat Model (Section 18.1 of [RFC6887]) to defend against some
>off-path attacks. 
>I already fixed the nits in my local copy.
>Thank you.
>-----Message d'origine-----
>De : Chris Inacio []
>Envoyé : dimanche 4 janvier 2015 07:57
>À :;;
>Objet : sector review of draft-ietf-pcp-server-selection-07
>I have reviewed this document as part of the security directorate¹s
>ongoing effort to review all IETF documents being processed by the IESG.
>These comments were written with the intent of improving security
>requirements and considerations in IETF drafts.  Comments not addressed
>in last call may be included in AD reviews during the IESG review.
>Document editors and WG chairs should treat these comments just like any
>other last call comments.
>Generally the document is in good shape, and I would like to see one
>minor issue at least commented upon.
>I have a single security related comment on this draft; the last sentence
>of section 3:
>> For efficiency, the PCP client SHOULD use the same Mapping Nonce for
>>   requests sent to all IP addresses belonging to the same PCP server.
>Normally, I would simply say this is a crazy recommendation.  But after
>looking a little into what the Nonce is used for in the PCP protocol, I
>am slightly less distraught.  This Nonce does not appear to necessarily
>provide any huge amount of security except allowing the client to
>generate a unique token per PCP server.  Presumably there is a general
>MITM attack on the PCP protocol related to the Nonce as a transaction ID
>which is prevented by using other security protocols, TLS, etc.  (And
>another well known attack with the THIRD_PARTY option and lack of
>authenticationŠ) Therefore, this Nonce is critical as a synchronization
>point between the client and the potential PCP server.  It would be nice
>(assuming all that is correct) to make that clear in the document,
>especially with a recommendation to reuse the Nonce.
>In Figure 1, the lines are not aligned to the ³+² on the diagrams.
>In Figure 3, ³rtr1² is missing a ³+² on the right side connection from
>the top.
>Chris Inacio