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

[<[e-mail]>]

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: [e-mail]; [e-mail]; Briscoe,RJ,Bob,DER3 R; [e-mail]; [e-mail]; 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:[e-mail]]
> Sent: 02 September 2009 02:43
> To: Magnus Nyström
> Cc: [e-mail]; [e-mail]; Moncaster,T,Toby,DER3 R;
> Briscoe,RJ,Bob,DER3 R; [e-mail];
> [e-mail]
> 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