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

From: Magnus Nyström <[email-masked]>
Date: Tue, 1 Sep 2009 16:45:30 -0700

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

---

From: Steven Blake <[email-masked]>
Date: Tue, 01 Sep 2009 21:43:19 -0400

Magnus,

Thanks for taking the time to review this document.

> Maybe useful to add a brief early section providing definitions of

Regards,

// Steve

---

From: <[email-masked]>
Date: Wed, 2 Sep 2009 10:18:06 +0100

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:[email-masked]]
> Sent: 02 September 2009 02:43
> To: Magnus Nyström
> Cc: [email-masked]; [email-masked]; Moncaster,T,Toby,DER3 R;
> Briscoe,RJ,Bob,DER3 R; [email-masked];
> [email-masked]
> Subject: Re: Review of draft-ietf-pcn-baseline-encoding-05
> 
> Magnus,
>

---

From: <[email-masked]>
Date: Wed, 2 Sep 2009 11:01:34 +0100

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: [email-masked]; [email-masked]; Briscoe,RJ,Bob,DER3 R; [email-masked]; [email-masked]; Eardley,PL,Philip,DER3 R
Subject: RE: Review of draft-ietf-pcn-baseline-encoding-05

Hi Magnus,

Toby