DCCP meeting, IETF57, Vienna
Chair: Aaron Falk
Notes: Gorry Fairhurst
Technical design review
----------------------------------------
------------------------------------
Meeting Objectives & Rules 5 min
Presentation by Aaron Falk (AF)
Introduced purpose of meeting, in particular, he urged people present to
look for:
Faulty Assumptions
Poor Design Decisions
Unnecessary Functions
Implementation / Deployment risks.... etc
slides
http://www.icir.org/kohler/dcp/ietf57/aaron-ietf57.pdf
----------------------------------------
------------------------------------
Charter Review 5 min
Presentation by Aaron Falk
----------------------------------------
------------------------------------
Spec Review 40 min
Eddie Kohler (EK) reviewed the spec (not the CCIDs).
slides:
http://www.icir.org/kohler/dcp/ietf5
7/eddie-ietf57-spec.pdf
----------------------------------------
------------------------------------
Expert Reviewer Comments 10 min
Presentation by EK
slides: eddie-ietf57-reviews.pdf
A summary of the comments from the expert reviews forwarded to the wg
mailing list. Expert reviewers were
GM = Greg Minshall (transport)
ER = Eric Rescorla (security)
JR = Jonathon Rosenberg (multimedia)
(Jonathan's review has not been received yet)
Design Reviewers:
SB = Steve Bellovin(Security design reviewer)
RA = Robin Austein (Architecture design reviewer)
MW = Magnus Westerlund (Multimedia design reviewer)
----------------------------------------
------------------------------------
Discussion 45 min
SIGNALLING CHANNEL
-----------------
Henning Schulzrinne (HS): Have you considered the potential use of
addresses by DCCP as a flow-id in an NSIS environments? - This may
prevent some things being done.
Here are some questions:
1) connection identification? - is this TCP-Like?
EK: YES
HS: This makes some of the nice things in NSIS no longer possible. I
thought the idea of DCCP was end-to-end signalling with congestion
control - but in NSIS you don't know what the next hop is (like you do when
one uses RSVP, and get a PATH message). So if you have a protocol that
sends a packet into blue yonder, and it is intercepted, then you can
short-cut the transition to the next hop .
2) What is the minimum number of messages before I can send data?
EK: Zero messages, there is no delay required you can send with the
setup. Three messages for many other connections (e.g. if you don't want to
use the connection setup messages)
SECURITY
--------
ER: It occurs to me that you may need to be worried about sequence
numbers as a security issue. The HMAC solution I proposed in the review is a
strawman with much better security, it's probably too costly, but I'd
encourage a look at other solutions.
A design could have an implicit high-order sequence number word (never
sent), that is combined with the signalled number. (This approach is
similar to use in ESP). This is much better that what is now in DCCP, but
not as good as HMAC (which is hard to beat).
SB: Currently one security assumption is that you can see part of the
stream, but it is unlikely for someone else to see the beginning with the
initial connect request. This isn't necessarily a good assumption to use for
your security model.
DCCP performs an identification exchange where the sequence number isn't
expected. .....
Even if the connection nonce were sent on all packets, that doesn't give us
better performance, so that wouldn't really help.
EK: The model is the same as TCP's: there is some protection if you see
data packets, but not the control exchange - but this isn't
necessarily to be expected.
MW: Some apps will use nonce exchange out of band. Ideally, nonces need a
signalling path which you can secure, i.e. a separate channel between
sender and receiver over which you can send the nonce from A to B
without other systems seeing it.
A & B know they are talking to each other when they get the
request/response messages.
MORE SIGNALLING
---------------
Jonathan Rosenberg: (JR) Use of DCCP for feature negotiation of
parameters seems odd. There are other ways to do this, and some
applications may in any case prefer these other mechanisms. One example is to
use a secondary signalling channel (like SIP) There are still denial of
service attacks possible.
EK: A separate signalling channel is not necessarily bad. We have
thought about this. But, if you use a separate channel, then the
application must then take all the stuff from the signalling channel then
the application then has to move the data between the two channels, and
this add complexity to the application.
Mark Handley (MH): We could also consider RTSP rather than SIP for
signalling the information. In the development of RTSP there was a strong
push to use this for data. We chose not to do it this way. If DCCP had been
around, we could use a more reliable mechanism to deliver this setup
information. DCCP provides a better basis. The other option is use TCP for
the signalling (or even for everything). But, then we don't have DCCP.
SIP does something different and has extra functions, it may be suited to
some cases.
JR: The drawback is you pay for the overheads using RTSP/SIP.
MH: In DCCP, you can piggyback this control data on the first packet.
JR: OK.
COMPLEXITY
----------
Dave Crocker: The diligence, thoroughness,and clarity of presenting this
here to people is great. I noticed in the list of reviewers, was there a
feedback on routing?
AF: Yes, the reviewers are in two parts (see both lists).
Dave Crocker: I thought this was just adding congestion control (CC) to UDP -
It seems we have introduced 8 features into DCCP, only 2 are related to
congestion control.
The option setup is particularly chatty. DCCP is in a TCP mode, it has a
lot of features, it is a connection protocol, not really a 'datagram'
protocol. You have complexity. Do you need this much complexity?
The answer will be yes in some cases, and no in other cases. This
increases technical risk. It's a wonderful set of experimental work. But is
it deployable in the near-term? If you can find a way more in line with
congestion control for UDP, then you would get a more compelling need for
this and earlier adoptions.
If you could build it this with this more limited, initial goal, you
could add some of the other features later. I'd like to see this made
simpler - that would be really helpful for much greater utility.
EK: To understand the consequences, should we try to throw out
connection setup and termination? It would be an interesting design
exercise to examine this. One way would be to rethink the design. We
could do this and send it on the list and figure out what we had left and
whether it was useful.
MH: We didn't set out to develop a complex protocol, we looked at all the
options and all the things we needed to do, and found we had designed
this.
CHECKSUMS
----------
HS: 1. DCCP has inherited the same TCP/UDP checksum (i.e. standard
internet checksum). Some other newer protocols have made different
choices, think of SCTP as an example.
HS: 2. What about congestion control and fragmentation ?
EK: Generally the DCCP design assumes use of PMTUD. An application can
request that PMTUD is not used, unless CCID says not i.e. unless this
violates the CCID design basis.
MH: We'd like advice on checksums. Checksums are easy to compute. If you
want to do a NAT then DCCP is similar to UDP, and makes this job easy. Is
this a weak reason?
HS: I was thinking of a more traditional CRC.
MH: We'd like advice!
HS (clarified afterwards): Code re-use across protocols is not a strong
argument for inheriting a checksum; I doubt that it takes place in
practice and that a checksum is a major issue - it's just one
subroutine
I don't have strong evidence but I believe where performance matters that
modern strong checksums (CRC and maybe the that were mentioned during the
IAB plenary, I think, something like UMAC or PMAC, but I probably didn't
catch the names correctly) are not appreciably less efficient than good ol'
16-bit sum. This should certainly not be taken as 'obvious' - somebody
needs to find out based on publications or such.
I should note that SCTP uses CRC32. RFC 3309 contains a lot of related
references.
EK: Incremental checksum update is possible with current choice, and not
with a CRC.
CONNECTION ESTABLISHMENT
------------------------
MW: If you use RTSP you'd need multiple channels. Connection
establishment is an important feature for DOS prevention.
SERVICE NAMES
-------------
Colin Perkins (CP): Cost of processing. DCCP adds a service name, does
this make it worse when you want to implement in an operating system.
Experience for RTP is that building big servers can be problematic. Does a
service name make it harder for implementers?
EK: We'd expect each port to have a name. So this is a one word lookup, you
don't need it once connection is started.
RECEIVER DROP STRATEGIES
------------------------
Steve Casner (SC): You suggest that an over-loaded receiver drops
packets from the head of the receive queue. Often this is the right thing to
do. There are other cases where this may not be the right response. Don't
use a fixed assumption.
EK: A DCCP API may present options to the application.
MH: We intended you could do either from the front or back of the queue
depending on what the application wants.
FIXED VS. VARIABLE PACKET SIZES
-------------------------------
SC: You say you need different CCs for constant vs. variable packet
sizes. But, you can't assume one regime or the other - you may
actually have a combination.
DOS PROTECTION
--------------
CP: In the presentation you said there were DOS attacks with mobility. What
are the DCCP mechanisms concerning this.
MH: The primary method is the sequence number check. There are many
issues.
MOBILITY
--------
CP: I'm surprised you included mobility support in DCCP. There are other
places in the stack where you can do this. It would seem this could be
done via the application or by mobile IP.
EK: There were comments about this on the slides in the reviewer
comments. The basic reason is application level solutions are hard.
HS: You may need to redo this, if the address changes. The cost at the
application level is hard.
MH: It is heavyweight to do this above DCCP. There are three design
options:
(i) You can do above the transport level- this is heavy.
(ii) Do this in transport - light (at least for DCCP, not looked at TCP
case)
(ii) Do this below transport - 2 problems - you can¹t assume
mobility; IPv4 mobility is not optimal. Mobile IP doesn't give very
optimal mobility for delay-sensitive apps.
DCCP gives more optimal solution - but doesn't solve all the problems
CP: Not sure of the mobility use case. Often may have a non-DCCP channel in
addition to the DCCP one - that would also be needed.
COMPLEXITY (AGAIN)
-----------------
Lixia: What is the fundamental goal/job of the protocol? Do we need all of
these considerations?
Sally Floyd (SF): My goal was to adding congestion control to UDP that
multimedia apps can use with ECN . It also adds congestion control on the
reverse path. Partial checksums also desirable to tune congestion
control response. DCCP is not a next generation congestion control.
Lixia: I said next generation of transport - not just CC.
SF: This not just a matter of adding CC - other issues appear, these are
documented in the IDs, so we have learned much.
MH: If you look at the features you need to do, so you can implement CC
there's more than you may first think. In fact, the world has moved on,
middboxes, security,etc are also important issues.
In some ways TCP is simpler in its ACK policy. You can't use
cumulative ACKs with congestion control if you don't have full
reliability.
AF: Need to close out this part of the discussion.
ER: When you move the connection between hosts do you reset the CC
parameters?
EK/MH: YES.
----------------------------------------
------------------------------------
---------------------------
Reviewer Feedback 10 min
Steve Bellovin:
Some random thoughts....
No real-time attacks....
- 12B for the header may be a lot - have you looked at header
compression?
- There are security issues with partial header - discussed more in
UDP-Lite particularly the impact with ESP (see latest draft).
- Same worries about sequence number checking
- Things are different from a security point of view because you choose to
work with packets rather than streams, may be easier to exploit?
- May want the API to pass down a pre-shared out-of-band secret with HMAC, to
act as a starting nonce?
- The service name bother me - this could be dangerous it presents 2
things with the same meaning port + name. Once you have two ways of doing
it, you need two checks, or they can exploited. An example is an
Operating system that treat low-numbered ports as privileged - but
midboxes don't do quite same thing (e.g. they open based on service
name)- can this be exploited? appropriate actions need to be defined.
- Mobility? Some security may help?
- Need to think about stream protocols
- Middlebox may be hard to setup (it will make life harder with
connection lookup - an index value in the header would save the work)
- Multihomed hosts, mobility is worth retaining for this.
---
Rob:
- I was not as scared about the overall size of protocol as some people
said. A lot is to do with congestion control, and this takes up a big part
of the TCP specs too.
- This reminds me of "Chaosnet" which uses service names like this.
- It would be more minimal and Middlebox friendly if we have a 16 bit
checksum. It would also be easier to use normal ports. Don¹t agree with HS
on the cheap CRC implementation, since anything not like UDP is likely to be
more hard for a middlebox to adopt.
- The feature negotiation: is "very California", lots of talk... does it
need to be like this?
- Slow-down [at the receiver] is under specified (too much left to be
guessed). TCP algorithms have to guess what the other end wants, we need to
be explicit.
- The sequence number space seems small. I know this is measured in
packets not bytes, but still this is not a big space, do we have to be so
careful with bits?
- I am underwhelmed by mobility, partial checksums
- Current specification of data request exchange has lots of optional
things - this would be really nice if they were to be fixed.
----
Magnus Westerlund:
- How do we get this deployed in the face of NATs?
---
SB: Multihomed hosts are important. It would be good to keep the
mobility feature for this reason alone. I think it is useful.
----------------------------------------
------------------------------------
Closeout Next steps 5 min
AF: Would like to track these ideas and changes. a version tracker would be
good.
Today is EK's birthday!
----------------------------------------
------------------------------------
|