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

<philip.eardley@bt.com> Thu, 03 September 2009 00:38 UTC

Return-Path: <philip.eardley@bt.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A613A697E; Wed, 2 Sep 2009 17:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level:
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38dLMoCHxaTC; Wed, 2 Sep 2009 17:38:34 -0700 (PDT)
Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 880443A68CC; Wed, 2 Sep 2009 17:38:34 -0700 (PDT)
Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Sep 2009 11:02:21 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 2 Sep 2009 11:01:34 +0100
Message-ID: <4A916DBC72536E419A0BD955EDECEDEC063637A5@E03MVB1-UKBR.domain1.systemhost.net>
In-Reply-To: <AEDCAF87EEC94F49BA92EBDD49854CC70CDCF280@E03MVZ1-UKDY.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-ietf-pcn-baseline-encoding-05
Thread-Index: AcorbsSAtSNNTUgqT9mBqK+tAyyKWAAPh+OwAAGi8ZA=
From: <philip.eardley@bt.com>
To: <toby.moncaster@bt.com>, <slblake@petri-meat.com>, <magnusn@gmail.com>
X-OriginalArrivalTime: 02 Sep 2009 10:02:21.0763 (UTC) FILETIME=[769DA130:01CA2BB4]
X-Mailman-Approved-At: Wed, 02 Sep 2009 22:54:29 -0700
Cc: bob.briscoe@bt.com, menth@informatik.uni-wuerzburg.de, iesg@ietf.org, sob@harvard.edu, secdir@ietf.org
Subject: Re: [secdir] Review of draft-ietf-pcn-baseline-encoding-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2009 00:38:35 -0000

Toby
Your suggestion is fine with me. I'd keep the note about this misconfiguration scenario short - if things are misconfigured, then they can be misconfigured in all sorts of ways and different things can go wrong. 

-----Original Message-----
From: Moncaster,T,Toby,DER3 R 
Sent: 02 September 2009 10:18
To: Steven Blake; Magnus Nyström
Cc: iesg@ietf.org; secdir@ietf.org; Briscoe,RJ,Bob,DER3 R; menth@informatik.uni-wuerzburg.de; sob@harvard.edu; Eardley,PL,Philip,DER3 R
Subject: RE: Review of draft-ietf-pcn-baseline-encoding-05

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."

Toby

> -----Original Message-----
> From: Steven Blake [mailto:slblake@petri-meat.com]
> Sent: 02 September 2009 02:43
> To: Magnus Nyström
> Cc: iesg@ietf.org; secdir@ietf.org; Moncaster,T,Toby,DER3 R;
> Briscoe,RJ,Bob,DER3 R; menth@informatik.uni-wuerzburg.de;
> sob@harvard.edu
> 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