Re: [secdir] Review of draft-ietf-pcn-baseline-encoding-05

<> Wed, 02 September 2009 09:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F40153A6817; Wed, 2 Sep 2009 02:19:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.625
X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OZWgArb+-XsK; Wed, 2 Sep 2009 02:19:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E33AE3A67F2; Wed, 2 Sep 2009 02:19:25 -0700 (PDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 10:18:12 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Wed, 02 Sep 2009 10:18:06 +0100
Message-ID: <>
In-Reply-To: <1251855799.12516.11.camel@tachyon>
Thread-Topic: Review of draft-ietf-pcn-baseline-encoding-05
Thread-Index: AcorbsSAtSNNTUgqT9mBqK+tAyyKWAAPh+Ow
References: <> <1251855799.12516.11.camel@tachyon>
X-OriginalArrivalTime: 02 Sep 2009 09:18:12.0474 (UTC) FILETIME=[4B8435A0:01CA2BAE]
X-Mailman-Approved-At: Wed, 02 Sep 2009 02:22:45 -0700
Subject: Re: [secdir] Review of draft-ietf-pcn-baseline-encoding-05
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, 02 Sep 2009 09:19:27 -0000

Hi Magnus,

As Steve said, thanks for reviewing the document. We did consider having a list of abbreviations at the start (and still do give the key definitions and their abbreviations). I would be happy to add a separate list of abbreviations if it was felt this would add clarity to the document.

As to injecting PCN-marked within the network: PCN is very clearly defined as working in a trusted environment where all nodes are expected to work together. So the only ways that PCN-marked packets might enter the PCN-domain mistakenly are 

1) If there is a misconfigured or otherwise "broken" node in the PCN-domain. It was felt that this is very firmly an implementation and operator management issue and thus beyond the scope of this document.

2) If a PCN-boundary node was misconfigured and mistakenly allowed in a PCN-marked packet or mistakenly set the mark itself. This again was felt to be a matter for the implementers and operators of the PCN-domain.

Having said that I would be happy to add a couple of sentence such as the following:

"Although spurious PCN-marks can only enter the domain as a result of misconfiguration, operators might wish to be aware of the potential impact of these marks. The precise impact will depend on which of the various proposed edge behaviour schemes is used, but in general such spurious marks will lead to either admitting fewer flows into the domain or possibly terminating too many flows. In either case good management should be able to quickly spot that there is a problem since the utilisation of the links in the domain will quickly drop off."


> -----Original Message-----
> From: Steven Blake []
> Sent: 02 September 2009 02:43
> To: Magnus Nyström
> Cc:;; Moncaster,T,Toby,DER3 R;
> Briscoe,RJ,Bob,DER3 R;;
> Subject: Re: Review of draft-ietf-pcn-baseline-encoding-05
> Magnus,
> Thanks for taking the time to review this document.
> On Tue, 2009-09-01 at 16:45 -0700, Magnus Nyström wrote:
> > 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 primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should treat
> > these comments just like any other last call comments.
> >
> > Overview:
> >
> > Loosely, this document describes a way of pre-congestion notification
> > marking of packets that builds on the Explicit Congestion
> Notification
> > (RFC 3168). The marking is only carrying meaning within a given PCN
> > domain.
> >
> > Comments:
> >
> > With the caveat of not being an expert in the field this draft is
> > about, I find the document relatively straightforward to understand
> > and the Security Considerations section reasonably complete (although
> > it perhaps would have been useful to describe what problems that
> > possibly could occur should a party inject PCN-marked packets inside
> a
> > network?).
> >
> > Editorial:
> >
> > Maybe useful to add a brief early section providing definitions of
> > abbreviations?
> >
> > -- Magnus
> Regards,
> // Steve