Re: [conex] Review of draft-ietf-conex-abstract-mech-06

[Bob Briscoe <[e-mail]>]

Mirja,

Tx for this. Matt & I were recently discussing 
how to get this one moving, given we hadn't 
really had many specific criticisms, so this is very useful - thanks.

I'll respond with my personal reactions, and 
leave my co-author, Matt, to come back on anything.

At 15:12 04/06/2013, Mirja Kühlewind wrote:
>Hi,
>
>sorry for the very late review. The draft reads actually very well. I only
>have some high level comments:
>
>1) The very long title of Figure 1 was kind of confusing me.

OK, we need a caption like "The flow of ConEx 
signals in the context of the pre-existing flows 
of congestion signals over an end-to-end connection"

Then fold the 3-sentence post-amble under the 
Figure into the body text, where it refers to the Figure.


>2) Section 'Overview' is very long (for an overview). Don't know if per-flow
>state, byte vs. packet and partial deployment needs to be discussed here.
>Maybe think about a subsection on discussion points instead (which could also
>include some discussion on attacks against the audit). On the other hand
>potentially introduce briefly the credit concept here.

Flow-state:
I'd be happy to move most of the first half of 
the para into an introductory paragraph under 
S.5.4. "Policy Devices" about flow-state. That 
would leave just a high level sentence about the 
trade-off in the introduction, with a pointer to S.5.4. Something like:

"  One of the design goals of the ConEx protocol is that the important
    policy mechanisms can be implemented for heavily aggregated traffic in the
    core of the Internet per logical link without 
per flow state (see Section 5.4).
    However, the price to pay for avoiding flow state for policy is flow state
    to audit ConEx signals, which is discussed further in Section 5.5.  In
    summary: i) flow state for auditing does not require route pinning;
    ii) auditing at the edges, with limited per flow state, enables
    policy elsewhere, including in the core, without any per flow state.
"


>3) Maybe define the term 'congestion signal' in section 2.1

Would the following change to the start of the 2nd para be enough:

OLD
    Networks indicate congestion by three possible signals: packet loss,
    ECN marking or queueing delay.
NEW
    Networks indicate congestion by three 
possible congestion signals: packet loss,
    ECN marking or queueing delay.


>4) I'm not sure that section 4.6 is at the right postion as it seems to me
>more related to requirements on the encoding.

We already have the two requirements sentences 
from Section 4.6 as items D & E in Section 3.3.

Would it fix your concern if, instead of just 
stating these two requirements, we make the 
SHOULDs lower case and refer back to the actual SHOULD requirements earlier:

OLD
    Therefore a ConEx encoding SHOULD explicity specify whether it
    assumes units of bytes or packets for both congestion indications and
    ConEx markings.

    [I-D.ietf-tsvwg-byte-pkt-congest] advises that congestion indications
    SHOULD be interpreted in units of bytes when responding to
    congestion, at least on today's Internet.  In any TCP implementation
    this is simple to achieve for varying size packets, given TCP SACK
    tracks losses in bytes.  If an encoding is specified in units of
    bytes, the encoding SHOULD also specify which headers to include in
    the size of a packet.
NEW
    This is why a ConEx encoding should explicity specify whether it
    assumes units of bytes or packets for both congestion indications and
    ConEx markings (see requirement D in Section 3.3.).

    [I-D.ietf-tsvwg-byte-pkt-congest] advises that congestion indications
    SHOULD be interpreted in units of bytes when responding to
    congestion, at least on today's Internet.  In any TCP implementation
    this is simple to achieve for varying size packets, given TCP SACK
    tracks losses in bytes.  If an encoding is specified in units of
    bytes, the encoding should also specify which headers to include in
    the size of a packet (requirement E in Section 3.3).


>5) Maybe address briefly how to handle ConEx-not-Marked and not ConEx-capable
>packets (not only for partial deployment but also in regular operation). They
>need to be limited somehow as well, otherwise a sender can easily cheat by
>sending ConEx-not-Marked. And this has to be done by the policer (and not the
>audit though).

I think you mean solely Not-ConEx.
(ConEx-Not-Marked means Conex-enabled but not 
marked - this highlights that we haven't defined 
that word well; Section 4.5. defines it with the 
same meaning as before, but it hasn't been defined before.).

There is a para about this in S.6, starting "A 
network operator can create incentives for 
senders to voluntarily reveal ConEx information. ..."

Nonetheless, that in a bullet about senders, so I 
would be happy to write something more specific 
in the section on policy devices, which is where 
this is more relevant. Also, a very simple 
sentence under audit, saying it ignores Not-ConEx.


>8) Section 5.5 doesn't give any advise how to handle encrypted TCP for loss
>estimation.

Perhaps this would be solved by moving Generic 
loss auditing before the more specific loss 
auditing bullets, because it basically says 
generic isn't possible. Then ending generic loss 
auditing with a linking sentence saying 
"Nonetheless, loss auditing is possible in the following specific scenarios."

In hindsight, we now have another way of doing 
generic loss auditing, which I'd like to add. A 
network can tunnel traffic and turn on ECN in the 
outer, just for the length of the tunnel. Then, 
by RFC6040, the tunnel egress will drop any 
ECN-marked packets with an the inner showing that 
the e2e transport is Not-ECN-capable.

So, an auditor at the tunnel egress will see all 
the congestion signals from within the network as 
ECN, then the tunnel egress will transform ECN 
into drop for those transports that don't support ECN.


>9) Section 5.5.1 introdues the credit concept. Not sure if the meaning of
>credits is well enough specified here. My personal option is that credits
>should somehow get invalid (at some point in time). This is left open in the
>current text.

I think we need to agree before we can talk about writing down what we agree...

Rather than thinking of Credit expiring after a 
time, one can think of the combination of recent 
Re-Echo signals and earlier Credit signals 
keeping the Credit state fresh within a flow. As 
long as you've sent Credit before a round of 
congestion, then if you send Re-Echo after the 
Auditor can switch it round as if you sent the 
Re-Echo before and the Credit after.

So, when the Auditor holds Credit, it allows up 
to that amount of Re-Echo to be considered as 
having been sent before the congestion, rather 
than after. Then, as it switches the Re-Echoes 
back in time, it switches the Credits forward, so they always stay recent.

Credit is primarily a mechanism to ensure the 
sender has to suffer some cost before it is 
trusted to pay back some cost. Credit doesn't 
need to degrade over time if the cost to the 
sender of introducing credit doesn't degrade over time.

Does this move us forward, or do you still 
disagree? If so, I suggest a new thread would be useful.


>10) In section 6 it is stated that 'Networks MUST NOT change ConEx marked
>packets to not_ConEx. [...]'. Maybe move this to the requirement section,
>otherwise it might be easily overread.

Yes. Thanks. And the same goes for collecting any 
the other later normative language into the requirements section.


>11) Security Considerations lists a number of 
>attacks. Shouldn't this document
>also give hints how to handle these attacks? Especially for the 'Dragging
>Down a Spoofed Flow ID', I can't really come up with a good solution...?

You're right that this is the hardest known 
attack to defend against. The draft currently 
refers to my thesis for two solutions. See Section 7.5.3 of
<http://bobbriscoe.net/projects/refb/#refb-dis>
It also includes an analysis of how difficult 
this attack is for a blind attacker. The attack 
only works while it sends numerous packets over a 
5-tuple that matches a target flow. It only has 
to scan the most fruiful parts of the 5-tuple 
space, but it can't detect when it has hit a 
match, so it has to send large numbers of packets 
over each 5-tuple just in case. BTW, the attack 
is trivial for a man-in-the-middle, but he can drop everything anyway.

I have promised to transcribe that material into 
the RFC series eventually, but it's not a 
priority before we get experimental use of ConEx. 
I believe it's OK at this stage as long as the 
solutions are documented /somewhere/ and referred to.

Is that acceptable?

Thanks v much for this full review. We needed this.


Bob


>Mirja

________________________________________________________________
Bob Briscoe,                                                  BT