Re: [dccp] dccp spec review (Rescorla)

[Eric Rescorla <ekr@rtfm.com>]

> > 2.0 General Comments
> > --------------------
> > The basic congestion control design appears to be sound. However,
> > I'm not an expert in congestion control, so I could easily have
> > missed something important here. However, there are some 
> > protocol engineering aspects not related to the functioning
> > of the congestion control mechanisms that I'm not so
> > thrilled with. I don't think the protocol is fundamentally
> > flawed, but I would prefer to see it undergo substantial 
> > modification before advancement.
> 
> We don't really see this from the rest of your comments. It seems like the
> main modification you would like to make is described in Section 2.1
> (response below). Is there something else?

Well, mobility, for starters. Anyway, that was my attempt to sum
things up. If you feel like the stuff I talked about isn't a substantial
change (but do want to make it) then that's fine by me :)


> > Naively, it seems to me that there will be two classes of traffic: (1)
> > more or less real-time traffic that happens to be over UDP, such as NFS
> > and to some extent RealAudio (2) Real-time traffic such as VoIP.
> 
> I'm not sure how things like multiplayer game traffic would fit in to this
> classification. Furthermore, more or less real-time video traffic would be
> another class of traffic that could use DCCP. 
Right, but with video the situation is the same as VoIP: you want to
back the codec off.

> > It probably doesn't matter whether it gets
> > CCID-2 or CCID-3, though based on the DCCP documents it
> > seems like TFRC might be a bit more responsive, which would
> > be nice.
> 
> Traffic that just wants to maximize its fair throughput should use CCID-2,
> TCP-like congestion control. CCID-3 is for traffic that is willing to
> receive somewhat less throughtput in times of variable congestion, in
> exchange for the privilege of not halving its sending rate in response to a
> single instance of congestion, but of reducing its sending rate more
> moderately.
>
> The CCID-3 draft says "TFRC congestion control is appropriate for flows
> that would prefer to minimize abrupt changes in the sending rate."
Right, but it's not clear to me what applications would really 
benefit from one or the other. What current applications do you
believe have drastically different utilities from CCID-2 and
CCID-3? Have you done simulations to observe the behavior?

> > The second kind of traffic doesn't really want congestion control
> > at all but rather wants congestion *indications* which get passed
> > up the stack to the application, which can then cut its codec
> > rate or send static or whatever. If we use congestion control,
> > then it's not clear that the right packets get dropped. 
> 
> You're referring to packets getting dropped by the sending congestion
> control mechanism, rather than the network, right?
Yes.

> You absolutely still need a congestion control mechanism to manage the
> moment-by-moment dynamics of congestion, detect loss and ECN markings,
> decide on allowable rates, and prevent misbehaving applications from
> sending more than they should. DCCP will provide that mechanism.
I can see how this might be the case, but I'm not entirely
sold.

> > 2.8 General Nits
> > ---------------------
> > Maybe I just missed it, but I couldn't see where in the document
> > the retransmit timers for the various setup handshakes were
> > specified.
> 
> We mostly specified timers by reference to TCP. For instance, for
> retransmitting DCCP-Requests: "The retransmission strategy SHOULD be
> similar to that for retransmitting TCP SYNs." Do we need to get more
> specific?
I would prefer to see it fully specified. Implementors do bad things
if you don't.

> 
> > S 5.1:
> >         This field is reserved for use by the sending CCID. In
> >         particular, the A-to-B CCID's sender, which is active at DCCP A,
> >         MAY send information to the receiver at DCCP B by encoding that
> >         information in CCval. DCCP proper MUST ignore the field. If the
> >         relevant CCID does not specify its value, it SHOULD be set to
> >         zero.
> > 
> > Why aren't reserved fields a MUST be zero?
> 
> I would rather keep the MUST ignore/SHOULD be zero. That way, intrusive
> middleboxes would be encouraged to really ignore the field, rather than
> reset/drop on nonzero. Middleboxes will ignore this particular field
> anyway, of course (because of CCID-specific values).
What's wrong with MUST ignore/MUST be zero?

> We do cite RFC 1948, in that paragraph:
> 
> 	In particular, initial sequence number choice
>         MUST include a random or pseudorandom component to make it
>         harder for attackers to complete sequence number attacks [RFC
>         1948].
My bad.

> > I would think that an implementation SHOULD rate-limit challenge options
> > it sends.
> 
> The Challenges are already congestion-controlled ("the receiving DCCP MAY
> send a DCCP-Ack packet to the sender, as allowed by the congestion control
> mechanism in use..."), so it isn't a risk to the network to leave this as a
> MAY...?
My philosophy is to give implementors as few choices as possible...

> > S 5.3:
> > I appreciate that the state machine is very complicated, but not having 
> > a picture is pretty painful here. 
> > 
> > Note: I haven't hand-verified the state machine yet.
> 
> We should have pointed you to the postscript, at:
> http://www.ietf.org/internet-drafts/draft-ietf-dccp-spec-03.ps
I've seen it--and I see why you didn't do ASCII art.

> ASCII art time for us... Whee!!
> 
> 
> > S 5.4:
> > What's the motivation for using a 32-bit service identifier?  This
> > seems like a false optimization, and it means that we absolutely need
> > a registry. There's plenty of room here to have something more
> > freeform. If you're really worried about bandwidth, have the high bit
> > mean "variable length" and register in the low 31 bits.
> 
> Mark: I *want* a registry. But the space is intended to be big enough that
> you can do FCFS allocation, without artificial space constraints.
>
> Eddie: We could make Service Name a mandatory variable-length option if
> people feel strongly about this.
My experience with registries is not good. That means registry policies,
etc. What's the virtue of this?

> > S 5.8:
> > Why have such short error reasons? I'm a big fan of having room
> > for a string, myself.
> 
> Strings can be hard for programs to interpret, so I don't want to lose the
> simple numeric Reason field. We could add an option containing an
> additional string.
That was what I meant to say. :)

> > Is there any reason why the Connection Nonces
> > shouldn't be always exchanged in the initial handshake?
> 
> In case the Connection Nonces were generated out-of-band using some
> cryptographic mechanism, for example. Maybe A and B have a shared key; they
> hash that key with the source and destination ports to get the Nonces. Then
> they know each other's Nonces without having to expose them in plaintext.
Could you explain this in the text.

> > S 6.4.3:
> > You should note that this code is for transmission.
> 
> Sure.
> 
> 
> > S 6.7:
> > What's aliasing noise?
> 
> When the endpoints have slow timer granularity, so the elapsed time value
> is always in a multiple of 1 ms, for example. Then a smaller value, like
> 0.5 ms, would be represented by a sequence of 0 ms and 1 ms values.
I think explaining this would be worthwhile.

> > S 7: 
> > Shouldnt these SHOULDS be MUSTS
> 
> "A DCCP SHOULD NOT send data when its Congestion Control feature is in the
> Unknown state." -- I guess we were thinking of allowing data on the
> DCCP-Request, but I agree with you, this could be a MUST.
> 
> "A DCCP implementation intended for general use---in a general-purpose
> operating system kernel, for example---SHOULD implement at least CCIDs 1
> and 2." -- I think this is OK as a SHOULD; it is not strictly required for
> interoperability, because CCIDs are negotiated.
I can live with that.

> > S 7.1:
> > I'm not sure what the rationale is here for prohibiting 
> > implementors from using CCID-1 as a proxy for vendor-specific
> > congestion control measures is. Unless you provide some
> > alternative, it seems to me that people will do it anyway.
> > 
> > Similarly, I'm not to thrilled about placing requirements
> > on APIs. We don't usually do that.
> 
> Eddie: We're trying to provide some strong advice about what CCID 1 is
> acceptable for. I think the alternative, given other WG/author feedback,
> would be to remove CCID 1, which would be a shame. Is there some middle
> ground?
> 
> Sally: People can do many things on their own, including disabling
> congestion control in TCP or in DCCP. It is still useful to make it clear
> that such things are not standards-compliant.
That's fine, but it's not the API that's noncompliant but the
API plus it being called.


> > S 8.4:
> > Something doesn't look quite right with the example in
> > 7.4. Shouldn't some of those packets be going from B>A? If not,
> > some more explanation is needed.
> 
> No, the example is correct. I'll flesh out the table with the corresponding
> B > A packets, and try to expand on the explanation.
I think that would help.


> We haven't, except for the thought experiments required to come up with
> Section 8.9. Which cost(s) in particular are you worried about? Space?
> Time?
Well, there's a lot of optimization here, so I'm wondering if it's
a particularly good optimization choice.

> > S 11:
> > This PMTU stuff worries me a bit. It seems like one might want
> > to periodically probe and see if one could reincrease the 
> > MTU. One good reason to do this is to prevent DoS attacks where
> > the attacker drives your MTU down to zero.
> 
> They'd probably have to guess sequence numbers to do that, right? Because
> of the embedded header in the ICMP NEEDFRAG?
Yes, I would think so.

> Nevertheless we could allow for such probing.
> 
> > Why are you making API recommendations here?
> 
> We feel that it makes the protocol issues clearer. It's important here, I
> think, because DCCP expects the application to do the framing, so PMTU
> discovery, though it's implemented by the protocol, must be transmitted up
> to the API. Should we change the description in some way?
> 
> 
> > S 12:
> > What's the purpose of making all these recommendations on 
> > middleboxes. I'm not a big fan of middleboxes but it seems
> > likely that if they would achieve some advantage by doing
> > the things that you forbid, they will do so in any case.
> > And if they wouldn't, then forbidding them is of marginal
> > value.
> 
> Eddie: The purpose of this section was to point out where middlebox
> behavior with DCCP will probably differ from TCP -- in particular, sequence
> number modification is much, much harder with DCCP. It's meant to help
> middlebox designers, not discourage them.
> 
> I believe that you are correct, middleboxes will do what they please; but
> this section will provide guidance and warn middlebox designers about
> potential ratholes. We could clarify that this is the intent of the
> section; would that help?
Maybe just remove the normative language.

> Sally: The advice in Section 5 of RFC 3360 on "Inappropriate TCP Resets
> Considered Harmful" is that, unfortunately:
> 
>    With the current modification of transport-level headers in the
>    network by firewalls (as discussed below in Section 6.2), future
>    protocol designers might no longer have the luxury of ignoring the
>    possible impact of changes to the transport header within the
>    network.
> 
> We are trying to address this issue, by discussing the robustness (or lack
> of robustness) of DCCP to actions by middleboxes. Putting text is a
> document of course does not control the actions of middleboxes. But it is
> not a viable option, in our opinion, to try to design a protocol to be
> robust to any arbitrary changes that a middlebox might make in packet
> headers. The best path seems to be increased clarity about what degree of
> robustness to middlebox actions is and is not being designed in to the
> transport protocol.
I'm fine with discussion. It's the normative stuff I don't
like.
  
> > S 18:
> > Under what circumstances would one actually want to have
> > separate error checks for the header and payload. I'm 
> > generally pretty skeptical of partial error checking.
> > I think an example is needed here to justify this feature.
> 
> Do you not like the example in that section already? It could use some
> tightening and additional description.
> 
>     These resilient applications might prefer to receive corrupted data
>     than to have DCCP drop a corrupted packet.  This is particularly
>     because of congestion control: DCCP cannot tell the difference
>     between packets dropped due to corruption and packets dropped due to
>     congestion, and so it must reduce the transmission rate accordingly.
>     This response may cause the connection to receive less bandwidth
>     than it is due; corruption in some networking technologies is
>     independent of, or at least not always correlated to, congestion.
>     Therefore, corrupted packets do not need to cause as strong a
>     reduction in transmission rate as the congestion response would
>     dictate (so long as the DCCP header and options are not corrupt).
I'm not convinced this is a real problem. Is there some network
where this actually happens to a substantial degree where one wouldn't be 
better off just using FEC?

> > 4.0 Security Issues
> > -------------------
> > I've been doing some thinking about the anti-spoofing and
> > anti-hijacking features in DCCP and I think that one can do a better
> > job given the same dataflow. As currently designed, an attacker who
> > can intercept any message now knows the current sequence number and
> > can forge packets. Now, eventually the sequence numbers are likely to
> > get out of synch and so you'll need to do an Identification, but
> > that's pretty distressing.
> >
> > It occurs to me that there's a simple solution that would dramatically
> > increase resistance to passive attacks where only a portion of
> > the data sequence (not the beginning) is available:
> > replace the checksum with a MAC keyed by the connection nonces
> > (obviously you'd need to exchange the nonce in the initial
> > handshake to make this work). With this change, no amount of
> > sniffing other than of the initial nonce exchange would
> > allow you to send false traffic . Since the checksum is very
> > short (16 bits) you would have a 1/2^16 chance with every
> > packet but no way to forge systematically, since you can't
> > recover the key. HMAC is probably fast enough for this purpose
> > but UMAC is faster and so might be a good choice.
> 
> I think the key question here is what a *transport* protocol should be
> doing (vs what the app should do, or what should happen below the
> transport protocol).
> 
> In particular, what does DCCP assume about IPSec?  And what does it
> assume about the cycles available for security?  
> 
> We've taken the attitude that a transport protocol should at the very least
> be secure to an attacker that cannot intercept the packets. This is also
> the level of protection provided by a good modern TCP implementation, and
> it is cheap to provide because it doesn't require the use of crypto. We've
> also assumed that protecting flows where the attacker cannot see the
> beginning of the flow is only a tiny delta on the existing mechanisms.
>
> (We did consider some mechanisms, a little similar to what you suggest,
> that would likewise protect against attackers who intercept only the middle
> of the connection. But we ended up deciding that the increase in security
> was too incremental to justify the cost and implementation complexity. For
> instance, consider your MAC suggestion: now we would need new mechanisms to
> support middleboxes that got introduced into the middle of a connection due
> to routing changes.)
You have that problem anyway--you need to renegotiate the nonces
or the Identification payload won't work, right?

> So we land firmly in the space of tradeoffs.  Strong security vs
> per-packet overhead.  Protocol complexity vs weak security.  
> 
> Questions:
>  1. Are we right to assume something like UMAC is too expensive for
>     some likely DCCP platforms?
I doubt it. All of the modern cryptographic hashes are extremely
fast. UMAC is even faster.

>  2. Are we right to assume that protecting a stream where the
>     attacker cannot see the beginning of the stream is not a
>     significant improvement?
I would say "modest". However, an additional advantage of this approach is
that it doesn't require a loss window/security tradeoff.

>  3. Is IPSec in fact too expensive for many applications than need to
>     use something like DCCP and need better that default security
>     against spoofed payload?
The problem with IPsec isn't cost but key management.

>  4. How much protocol complexity is too much in this space?
This is a pretty small complexity delta.

>  5. How much should we consider middleboxes' need to understand a data
>     stream as a high-priority requirement?
I'm not sure where this comes in... what I suggested doesn't
change that.

-Ekr

_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html