Skip to main content

Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements
draft-ietf-conex-abstract-mech-13

Yes

(Martin Stiemerling)

No Objection

(Alia Atlas)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Spencer Dawkins)
(Ted Lemon)

Note: This ballot was opened for revision 13 and is now closed.

Martin Stiemerling Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2014-12-04) Unknown
I am glad for the existence of this document. Thanks for taking the time
to write it.

Alissa's first comment needs to be addressed.
Alia Atlas Former IESG member
No Objection
No Objection () Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2014-12-03) Unknown
= Section 2 =
"This document extends the capabilities of the Internet protocol suite
   with the addition of a new Congestion Exposure signal."

This document doesn't do that, right? Maybe one of the standards-track conex documents will, but this document does not directly affect the Internet protocol suite.

"ConEx represents a recognition that the
   IETF cannot regulate this space directly because it concerns the
   behaviour of users and applications, not individual transport
   protocols."

I'm not sure what "ConEx represents" means here, but no matter which way I interpret it I have a hard time getting to the conclusion that this sentence makes. I would recommend that this sentence and the one that follows it focus on the implications of the abstract mechanism described in this document, rather than on what the IETF does or does not do.

= Section 4.4 =
"As long as the packets in a flow have uniform sizes, it does not
   matter whether the units of congestion are packets or bytes.
   However, if an application sends very irregular packet sizes, it may
   be necessary for the sender to mark multiple packets to avoid being
   in technical violation of an audit function measuring in bytes (see
   Section 4.6)."

This makes me wonder how the sender is supposed to know whether an audit function at any given point on the network is counting in bytes or in packets, or what happens if the same packet/sender encounters audit functions on two different networks (in a single path, or in a multi-homed sender scenario) that count using different units. The requirement in Section 4.6 that the encoding scheme specify its assumption about units isn't sufficient, because packets that use the scheme could encounter an audit function that makes the opposite assumption. Is this addressed somewhere?
Barry Leiba Former IESG member
No Objection
No Objection (2014-11-22) Unknown
I submit that a good number of the references really are normative, in that understanding them is necessary in order to understand this document.  I'd like to see the authors sort that out, and make an appropriate split in the references, so readers can know which ones truly do just add extra detail (informative), and which provide necessary background (normative).  That said, I don't consider that important enough to this document to block on it, so this is a non-blocking comment.  Please consider doing this, but there is no need to respond to me about it.  Thanks.
Brian Haberman Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection () Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2014-12-03) Unknown
Thanks for your response and agreed changes per the SecDir review.
https://www.ietf.org/mail-archive/web/secdir/current/msg05057.html

The draft looks good, thanks for your work on it and the detail level for security requirements like the specific requirements to protect against several attacks that may lead to a DoS in section 3.2 Audit.  

I found the first paragraph of 5.4 helpful to better understand what was intended by the term audit and think it would have been good to have that understanding a little earlier in the draft.  I was looking for possible security concerns that don't apply once I read this definition.
Spencer Dawkins Former IESG member
No Objection
No Objection () Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2014-12-04) Unknown
(Apologies, I only had time to skim this one, so
my comments might be a bit off the mark - feel
free to tell me I'm being dumb if so:-)

- The IPR declaration says licensing is to be provided
"later" though a note in fact does seem to contain a
(nice) set of terms. Might be good to fix?

- Could conex signals be used as part of an oracle
attack? I'm not sure they could but has someone
thought about that? If not, and if there were a way in
which to abuse conex along those lines then it could
be that stating a requirement that specific protocols
consider this would be a good idea. Note that I'm not
sure if a feasible way to use conex in such an attack
exists. If it did, a simple countermeasure might be to
just not allow for very fine-grained signals.

- It'd be good if the security considerations here
considered how more and more use of ciphertext might
affect conex, in particular for the proxy or audit
functionality. For example, is there any interplay
with what tcpinc is likely to produce?
Ted Lemon Former IESG member
No Objection
No Objection () Unknown