Re: [PCN] lets try again - a chair asking this time

[Bob Briscoe <[e-mail]>]

Ruediger,

[Scott, a question for you at the end]

At 08:07 21/03/2012, [e-mail] wrote:
>Hi Scott,
>
>the passage you quote should result from a misconfiguration or an attack.
>
>       Treatment of non-PCN-packets confused with a PCN-packet
>       due to DSCP/ECN codepoinzt setting:
>       ...
>       In the absence of any operator-specific
>       configuration for this case, by
>       default an implementation SHOULD re-mark
>       the DSCP to zero.
>       ...
>       Clearing the ECN field is not an appropriate
>       policing action, because a network node ought not to interfere
>       with an e2e signal.  Even if such packets seem like an attack,
>       drop would be overkill, because such an attack can be neutralised
>       by just re-marking the DSCP.  And DSCP re-marking in the network
>       is legitimate, because the DSCP is not considered an e2e signal.
>
>What's done here is remarking of a flow with a DSCP that has been
>agreed between two parties. On a consumer UNI, this may be an attack,
>on an NNI, this could indicate a misconfiguration.

Yes, when I realised this could be a mistake or an attack, I realised 
remarking the DSCP was the right approach to recommend, because it 
allows the operator to control this as part of their general DSCP 
re-marking policy.

BTW, the default of "re-mark to zero", was merely so /implementers/ 
have a default. It's not intended to be the recommended policy for operators.

>In the latter case,
>a management alert seems reasonable. Text to that may be added.

Good catch. In fact, an alert for an attack is also worth suggesting. 
I suggest the following text after "...re-mark the DSCP to zero (000000)."

"Whichever policing action is chosen, the PCN-ingress-node SHOULD log 
the event and MAY also raise an alarm. Alarms SHOULD be rate-limited 
so that the anomalous packets will not amplify into a flood of alarm messages."


>I further quote the PCN architecture, which is informational, on the
>Ingress Node behaviour:
>
>       Police - police, by dropping any packets received with a DSCP
>       indicating PCN transport that do not belong to an admitted flow.
>       (A prospective PCN-flow that is rejected could be blocked or
>       admitted into a lower-priority behaviour aggregate.)  Similarly,
>       police packets that are part of a previously admitted flow, to
>       check that the flow keeps to the agreed rate or flowspec (eg, see
>       [RFC1633] for a microflow and its NSIS equivalent).
>
>This isn't in line with the proposed 3-in-1 (standards track) behaviour.

You're right. When we wrote this point in the architecture I think we 
were only thinking about blocked flows. I don't think that text was 
intended to catch packets that had never even asked to be admitted 
(i.e. mistakes or attacks).

>Does this require an "Errata" atatement for RFC5559 (I'm not an expert on
>editing RFCs and may be wrong here)?

You're right that something needs doing about this statement in the 
architecture. We could say in 3-in-1 that it updates RFC5559. That 
would require an extra section in 3-in-1 saying exactly which part of 
the architecture it updates.

I prefer your erratum suggestion because it flags the problem in the 
doc that now needs clarifying, so it's more likely to be noticed by 
people reading the deprecated text. But we'll have to see whether 
this would be accepted as an erratum. The relevant rule is #7 here:
<http://www.ietf.org/iesg/statement/errata-processing.html>

"Changes that modify the working of a protocol to something that 
might be different from the intended consensus when the document was 
approved should be either Hold for Document Update or Rejected. 
Deciding between these two depends on judgment. Changes that are 
clearly modifications to the intended consensus, or involve large 
textual changes, should be Rejected. In unclear situations, small 
changes can be Hold for Document Update. "

If we wrote an erratum to RFC5559, it would be legitimate, because 
the para you have quoted has two contradictory statements in it 
anyway. I doubt an erratum can refer to an RFC published later 
(3-in-1), because errata are meant to correct what the document 
should have said at the time. I think we could compose an erratum 
that resolved the contradiction in that paragraph while at the same 
time making it "not inconsistent" with what we now want to say in 3-in-1.

Scott, can you advise?


Bob


>Regards,
>
>Ruediger
>
>________________________________
>
>From: [e-mail] [mailto:[e-mail]] On Behalf 
>Of Bradner, Scott
>Sent: Tuesday, March 20, 2012 5:37 PM
>To: [e-mail]
>Subject: [PCN] lets try again - a chair asking this time
>
>
>please let the list know what you think
>
>Scott
>
>Scott O Bradner
>Senior Technology Consultant
>
>
>
>Begin forwarded message:
>
>
>
>
>
>                 Date: Mon, 12 Mar 2012 03:30:11 +0000
>                 To: "PCN IETF list" <[e-mail]>
>                 From: Bob Briscoe <[e-mail]>
>                 Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt
>
>                 PCN folks,
>
>                 Following IESG review (particularly Adrian Farrel's 
> being the most comprehensive and useful), we've posted a new 
> version of the PCN 3-in-1 encoding.
>
>                 As well as a number of editorial changes, some 
> technical changes were needed in order to satisfy Adrian's request 
> to specify exactly what an implementer has to do at the ingress to 
> allow ECN to co-exist with PCN, and what defaults should be set to.
>
>                 In particular, for a non-PCN packet (i.e. doesn't 
> match any flow-state) that clashes with a PCN DSCP and is 
> ECN-capable, the recommended choice of 3 is:
>
>                       *  re-mark the DSCP to a DSCP that is not 
> PCN-compatible;
>
>
>
>
>                 [...]
>                 In the
>                       absence of any operator-specific
>                 configuration for this case, by
>                       default an implementation SHOULD re-mark
>                 the DSCP to zero.
>
>
>
>                 Actually, the whole of the ingress behaviour 
> section (5.1) has been re-written, incorporating material that was 
> previously repeated in both edge-behaviours (agreed with IESG and 
> with edge-behaviour authors, of course). Altho it largely does the 
> same thing technically, it is written to cover the complete range 
> of possible scenarios, and it now gives defaults and recommended 
> choices. I don't think it's controversial, but shout if it is.
>                 < 
> http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 
> <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1>  >
>
>
>
>                 Bob
>
>                 PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09:
>
>                       *  Added note about fail-safe to protect 
> other traffic in the
>                          event of tunnel misconfiguration.
>
>                       *  Changed section heading to be about applicability of
>                          environments to the encoding, rather than 
> the encoding to the
>                          environments.
>
>                       *  Completely re-wrote PCN-ingress Node 
> Behaviour section.
>
>                       *  Changed PCN interior node to PCN-node 
> where the term was
>                          intended to include all PCN-nodes.
>
>                       *  Clarified status of ECN/PCN co-existence 
> appendix.  Removed
>                          inconsistent assertion in this appendix 
> that an admission-
>                          control DSCP alone can indicate that 
> arriving traffic is PCN-
>                          traffic.
>
>                       *  A few clarifying editorial amendments and 
> updated refs.
>
>
>
>
>
>                         From: <[e-mail]>
>                         To: <[e-mail]>,
> 
><[e-mail]>, <[e-mail]>,
>                                 <[e-mail]>, <[e-mail]>
>                         Date: Sun, 11 Mar 2012 17:52:23 -0700
>                         Subject: New Version Notification - 
> draft-ietf-pcn-3-in-1-encoding-09.txt
>
>                         New version (-09) has been submitted for 
> draft-ietf-pcn-3-in-1-encoding-09.txt.
> 
>http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt
>
>
>                         Diff from previous version:
> 
>http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-3-in-1-encoding-09
>
>                         IETF Secretariat.
>
>
> 
>________________________________________________________________
>                 Bob Briscoe,                                BT 
> Innovate & Design
>
>         ________________________________________________________________
>         Bob Briscoe,                                BT Innovate & Design
>
>
>_______________________________________________
>PCN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design