Subject: Re: [Tsvwg] Some comments on draft-ietf-tsvwg-ecn-tunnel-00

From: Bob Briscoe <[email-masked]>
Date: Mon, 27 Oct 2008 18:52:09 +0000

Anil,

At 15:46 21/10/2008, Agarwal, Anil wrote:

Bob,

One quick comment on your excellent draft rfc –

I'm glad you're reviewing this, because it's potentially important stuff
- effectively a proposed change to the IP layer, albeit minor.

You could add some explanatory text for figure 3. Some of the entries in
the table are not intuitive.

OK - unfortunately I just posted a -01 update before finding this email -
I'll add the explanations you request to the -02.

The basic explanation is that this table is a re-statement of what is
already in RFC3168 (the ECN RFC, which is where the explanations are). It
is also what RFC4301 does for IPsec. There are good reasons for most
stuff. I'll try to explain inline below...

For example, the following table
contains some different suggested values, which may be better (?).

The rationale for dropping if the inner is Not-ECT but the outer is ECT:
no legal transition could ever have led to this situation, so something
must be misconfigured. Due to the misconfig, congestion might have been
missed. As the inner shows that the e2e transport only understands drop,
it's safest to drop such packets. True, this is harsh, but ...

I also took off the (!!!) from the
entry [outer ECT(1), inner CE].

This couldn't have happened through a legal transition. So why don't you
think an alarm should be raised? In fact, I've just added (!!!) to two
more cases in the -01 draft just posted.

+---------------------------------------------+

|           Incoming
Outer
Header
|

+---------------------+---------+-----------+-----------+-----------+

|    Incoming Inner   | Not-ECT
|   ECT(0)  |   ECT(1)
|     CE    |

|
Header
|
|
|
|           |

+---------------------+---------+-----------+-----------+-----------+

|
Not-ECT       | Not-ECT |
Not-ECT   |
Not-ECT
| drop(!!!) |

|
ECT(0)       |  ECT(0) |
ECT(0)  |   ECT(0)  |
CE    |

|
ECT(1)       |  ECT(1) |
ECT(1)  |   ECT(1)  |
CE    |

|
CE         |
CE   |     CE
|    CE     |
CE    |

+---------------------+---------+-----------+-----------+-----------+

|
Outgoing
Header
|

+---------------------------------------------+

It might also be useful to describe under what circumstances one might
get combinations such as -

[outer ECT(0). Inner Not-ECT], [ECT(1),
Not-ECT],
both only misconfig (see above)

[ECT[0], ECT(1)],

misconfig (the new -01 draft puts !!! beside this
one)

[Non-ECT, ECT(0)], [ECT(0), CE] and
so on
Both limited functionality mode of
RFC3168

and whether such behavior is
disallowed, discouraged or is acceptable under specific
circumstances.

This is all about 'forwards compatibility'. A transition that was illegal
under all current and previous incarnations of ECN tunnelling (there have
been lots) might find some future use.

So I've said operators MAY raise a warning (as long as they rate limit
warnings). Then if they got lots of warnings, they might investigate and
find a new behaviour has been standardised, so it's now OK. Then they can
ask for an update for the code that generates the warnings to meet
whatever new spec has been defined.

I figured this is a good way to allow evolvability but also ensure anyone
trying to use protocol fields outside the specs gets flagged as a
possible security threat, without automatically discarding all their
packets.

I could have said they SHOULD NOT drop if the table says they shouldn't.
Do you think I should say this?

I can post this email to the tsvwg mailing group if you think that is the
proper place to discuss this.

I've taken this as permission to cc.

Finally, see the new Appendix C in the -01 draft which focuses on a new
proposal for Fig 3. I haven't made this appendix part of the normative
body of the draft this time round, but I've now convinced myself I should
for the -02 draft.

Do you / others agree with my arguments for doing this in Appendix
C.1?

Cheers

Bob

Regards,

Anil

Anil Agarwal

ViaSat Inc.

Germantown, MD 20876

____________________________________________________________________________

Bob Briscoe, <[email-masked]>
Networks Research Centre, BT Research

B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5
3RE,UK.    +44 1473 645196