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

[Matt Mathis <[e-mail]>]

Follow up to Mirja's and Bob's comments, inline.   most are "Looks Good to
Me".


On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe <[e-mail]> wrote:

> At 15:12 04/06/2013, Mirja Kühlewind wrote:
>
>>
>> 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.
>
This is supposed to be a caption (not a title), but yes the RFC formatting
is confusing.   I would suggest something even simpler "The flow of
congestion and ConEx signals."  and move the rest into the running text.

>
>  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.
>
> "
>

I would make the 2nd part even simpler  "A suitable auditing design enables
policy elsewhere, including 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.
>

LGTM

>
>  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).
>

LGTM


>  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.
>

 I want to think about this one more: propose something more specific.

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

> estimation.
>>
>
Today essentially all encryption is above TCP, because IPsec does not play
nice with NATs, and I can't see that changing.    Furthermore there is
already quite a menagerie of FW class devices that refuse non-TCP and TCP
with nonsensical sequence numbers (to thwart various injection attacks).
 We already encrypt nearly all of our payload, except some services and
some countries.

It feels like this is important from pedantic completeness standpoint but
not much of an issue in the real world.

Let me think about this before you reorganize the section.

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.
>

This isn't really audit is it?  What happens if a transport says it can do
ECN, but just ignores it?

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...
>

I think that abstract-mech needs to embrace *both*, explicitly if not
implicitly.  I need to think about this some more, but I suspect that it
means we have unnecessarily over constrained audit here.


> 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.
>

This is probably correct, but I really don't think it belongs in A-M.


>  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.
>

Yep, I agreee

>
>
>
>  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<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?
>

LGTM

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

Except for the couple of items for more thought, dig in!

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.