Subject: [tsvwg] comments on draft-ietf-tsvwg-ecn-tunnel

From: <[email-masked]>
Date: Thu, 9 Jul 2009 14:42:59 +0100

Better copy these comments to the working group!

Toby

-----Original Message-----
From: Moncaster,T,Toby,CXR9 R 
Sent: 01 July 2009 17:43
To: Briscoe,RJ,Bob,XVR9 BRISCORJ R
Subject: RE: Calling in your offer to review draft-ietf-tsvwg-ecn-tunnel

Hi Bob,

I probably was silly enough to volunteer! I also remember volunteering
to review a couple of other IETF things back in March that are no doubt
going to catch up with me soon! Will do my best to make this a useful
(e.g. constructive) review...

Abstract:

Seems to lack detail of what you are expecting people to do having read
this. Need to clarify that whilst this updates RFC4301 & RFC3168 it only
ADDS functionality to 4301 (in other words 4301 compliant endpoints will
always be a subset of those compliant with this standard).

Introduction:

Overall - seems a bit over-long and gives too much detail both about
WHAT you are intending to do and WHY. I would suggest summarise the what
and concentrate on the why (as that is going to get less explanation in
the rest of the document).

Make it clear from the start that you are trying to impose a common set
of rules on this. Something like "currently the behaviour of IP-in-IP
tunnel endpoints is not consistent, with consequent risk of
misconfigurations etc etc..."

Make it more obvious that the changes on entry are to bring all current
behaviours into line. And thus that the major changes are at the
egress...

Re-cap of ECN is irrelevant for this document - you can sum this up in 1
sentence here and move the table into a later section or an appendix...

You still seem to have too much justification text explaining why this
situation occurred - this could be fine later on but is too detailed for
the intro.

" As a result, an unfortunate sequence of standards actions has left us
with nearly the worst of all possible combinations of outcomes, despite
the best endeavours of everyone concerned."
Sounds political to me (your telling them they screwed up but you try to
sugar the pill). Only really need to say that we have ended up with
contradictions (and I believe it is more that the different groups were
trying to second-guess each other rather than because they were
expending their best endeavours).

You mention PCN twice - first as the reason for needing to do something
now then as the main motivator for doing anything at all. I would
suggest stick to the first take - PCN highlights the absurdity of the
current situation so now is the time to do something. However longer
term this is going to sound strange once PCN is standardised and this is
accepted so it might be worth pointing out this text is not relevant to
the standard itself?

1.1 Scope - this seems fine. 

1.2 Document Roadmap seems fine (but hides the presence of many more
appendixes)

Section 3.

Could this become mainly Appendix material? Keep a summary, but cut the
length? Are you effectively defining the term "resetting" an ECN
codepoint? If so have a definitions section...

"But if non-IPsec tunnels are already present within a network to which
PCN is being added, that is not particularly helpful advice." - indeed,
but it is exactly as unhelpful to define a new set of standards
behaviours!!!

Section 3.2 can certainly be shorter...

Section 4 is the main point of the document... Make it clear this is the
case

In figure 4 include a footer describing the meaning of (!!!) as some
people will fial to read through the actual text...

4.1

"Compatibility mode is the same per packet behaviour as the ingress end
of RFC3168's limited functionality mode." --> Compatibility mode behaves
the same as the limited functionality mode in RFC3168 but only applies
at the tunnel ingress.

4.2
First bullet below figure 4 "If the inner ECN field is Not-ECT the
decapsulator MUST NOT propagate any other ECN codepoint in the outer
header onwards." --> If the inner ECN field is Not-ECT the decapsulator
MUST NOT propagate any other ECN codepoint forwards.

First sub-bullet below figure 4 - I believe this may be actually defined
in RFC4774 as the only safe behaviour. Probably worth spelling out that
the issue is that the congestion mark may not get reported back to the
sender.

3rd bullet - would be nice to explain the SHOULD (do you log every time,
or just log that it has happened; what circs is it ok not to log these)

As section 4.3 is informative it would be clearer to move it into its
own section (so all the normative text is in a single place).

End of 1st proper para: "Therefore here we give guidance for designing
possibly different marking schemes." Is very clunky... do you mean
guidance for designing different marking schemes, possible different
marking schemes, marking schemes that possibly differ,...

First bullet: xref to RFC4774 which has strong parallels with this
advice. I know 4774 is badly written but people are going to notice that
there is overlap between these and so it would be good to reference it
(e.g. "RFC4774 provides guidance on overloading the ECN field...")

3rd bullet - the only instance this bullet actually covers is that of
not ECT on the inner header so why not just say this?

5. End of 1st para. Highlight that this is a big advantage as it is
likely to reduce possible misconfigurations

Near the end you have some normative text - this is adrift of the main
block of such text so should actually be in section 4 (although the
explanations for it can be here).

Section 6: can this be presented in concise bullets at the start of the
section? E.g. this updates 3168 in following ways... etc

Section 8 - I suggest having the details of the Nonce hole put into an
Appendix with an xref from here...

Update references especially RFC5559 PCN!

Appendixes - I take it eventually these will get significantly reduced
and are really there for the purposes of explanation during
standardisation? The following comments are if you are going to keep the
appendixes...

App A.1 This seems to be a mixture of security 101 (as the Americans
would put it) and specific stuff for this actual work. Do you need all
the tutorial stuff?

A.2 Sure this could be a bit more concise!

A.3 This seems the right sort of level of detail

B.1 can any of this be explained by a suitable reference?

B.2 & B.3 Seem excessively detailed given you now have more or less
convinced people this is worthwhile work.

Appendix D title is slightly ambiguous (you have to work out where the
emphasis goes...).

HTH

Toby

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 09 Jul 2009 22:20:22 +0100

Toby,

Thanks for this.
If I say nothing I agree. Otherwise I push back inline...

>always be a subset of those compliant with this standard).

OK. It will have "Updates RFC3168 & RFC4301" in the headers. But as 
so many people have asked for this in the abstract too, I guess I'll 
have to oblige.

>sentence here and move the table into a later section or an appendix...

Agree with the rest of your comments about intro, but not this one. 
This doc has to be read & understood by IPsec implementers and IPinIP 
tunnel implementers who don't have ECN burned in to their skull like we do.

>expending their best endeavours).

No, this is actually true as I understand it. When 3168 was written, 
covert channels were identified as a vulnerability (from memory I 
think David Black did in his draft on ECN tunnels at the time). But 
at that time, ECN was a tiny side-show for the security area, so if I 
had been in the security area, I wouldn't have stuck my neck out to 
say covert channels were less important than ECN's control loop. 
Then, when IPsec was being updated, the security area had no right to 
change all tunnels, just because they were changing IPsec tunnels. 
This caused the perversity we have now with only non-IPsec tunnels 
blocking covert channels.

>accepted so it might be worth pointing out this text is not relevant to

I've had other comments asking for substantial reduction of the 
Intro. I'll try.

>length?

Michael Menth (I think) suggested I keep only the material 
summarising ECN here, and move material explaining why it needs 
changing to after I specify what to change in Section 4 (when it will 
make more sense). That's what I'll do.

>Are you effectively defining the term "resetting" an ECN

OK. Thoughts on other terms that could be defined:
Ingress/encap; Egress/decap; Incoming Hdr; Outer Hdr; Inner Hdr; 
Outgoing Hdr; Resetting ECN; Copying ECN.

>but it is exactly as unhelpful to define a new set of standards

Not so.
- If a standard is defined, an operator can tell a vendor it wants 
equipment that complies with the standard.
- If a standard isn't defined, all an operator can do is read a 
sentence saying "If you want PCN and tunnels: tough - it won't work".

>people will fial to read through the actual text...

No need to duplicate. If people want to know what it means, they will 
find where it says what it means. If they don't, they won't.

>the same as the limited functionality mode in RFC3168 but only applies

Yes, with the addition of "per-packet", which is important, as a 
tunnel end-point also has set-up behaviour.

>own section (so all the normative text is in a single place).

But, even if it were a section, rather than a sub-section, it would 
be logical to have it at the same point (as it repeats the same 
reasoning for the changes just made in S4.1 & 4.2). So it makes no 
odds whether it's subsection or section, it still goes normative, 
informative, normative.

>likely to reduce possible misconfigurations

I'm not a great fan of repeated self-praise in a standards track doc. 
That can be done on mailing lists when people argue. But if the 
arguments are won, there's no need to have on record how good the 
author thinks their idea is. But I will collect this sort of thing at 
the start where the motivation is written.

>explanations for it can be here).

I hadn't intended S.5 to be non-normative. But I like your idea. I'll have
- a sub-section of 4 where I give the normative stuff about modes.
- a section 5 that starts with a sub-section "Changes From Earlier 
RFCs" (currently S.6)
- Then further subsections explaining the non-impact of the changes 
on interworking etc.

>section? E.g. this updates 3168 in following ways... etc

Gorry has asked that I categorise changes for each RFC separately.

>would put it) and specific stuff for this actual work. Do you need all

Many in the transport area don't know security 101 (same reason for 
the ECN 101 in the intro for security area people).

>A.2 Sure this could be a bit more concise!

I'll mark it for editing down, but it's not my priority at the mo, 
unless I have time.

>B.1 can any of this be explained by a suitable reference?

I'm going to remove the whole of B.

To answer your question, no, the identifier stuff is all new. And the 
rest is all stuff I worked out (using David Black's similar ideas in 
RFC2983) in order to make sense of the interaction between tunnelling 
& sub-path control loops.
It's actually important architectural stuff, but having used it to 
work out what standards actions are appropriate, it's no longer 
necessary in this doc.

>Appendix D title is slightly ambiguous (you have to work out where the

OK

>HTH

Greatly. Thanks.

Bob

>Toby

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research

---

From: <[email-masked]>
Date: Fri, 10 Jul 2009 15:43:28 +0100

Couple of responses inline

Toby

> From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Sent: 09 July 2009 22:20
> To: Moncaster,T,Toby,DER3 R
> Cc: [email-masked]
> Subject: Re: [tsvwg] comments on draft-ietf-tsvwg-ecn-tunnel
> 
> Toby,
> 
> Thanks for this.
> >Re-cap of ECN is irrelevant for this document - you can sum this up
in
> 1
> tunnel implementers who don't have ECN burned in to their skull like
we
> do.

But they don't necessarily need it in detail in the intro was more my
point. Perhaps make it a subsection with a first sentence something like
"recapping ECN for those that are unfamiliar"

> Outgoing Hdr; Resetting ECN; Copying ECN.

Agree - makes exact scope of doc clearer if you define exactly what you
mean by terminology

> find where it says what it means. If they don't, they won't.

Can't see why it would hurt to clarify in the diagram, but I guess it's
a pretty minor point

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 10 Jul 2009 16:39:50 +0100

Toby,

I'm thinking of putting the ECN codepoints table in the terminology 
section. But it depends whether I can write an intro that makes sense 
without using precise ECN terminology. I'll try.

Adding "recapping ECN for those that are unfamiliar" makes sense.

Reason for avoiding definition of (!!!) in Fig: It needs to be 
precisely defined, and if I put a brief definition in the Fig, 
there's a danger people will only read the Fig and ignore the precise text.
(I'm a culprit, so I know others might do the same.)

Bob