Chair: Ted Faber
November 10, 2005
Notes by Aaron Falk
- TCPSECURE: in major edit
- ANTISPOOF: revised, may be ready for WGLC
Joe Touch: getting a little feedback with fixes, will revise
Q: have read? a few.
- NCR: clarifications sought, new revision coming, WGLC soon
- NCR/DCR (merged); seeking experimental status WGLC in Feb06; to IESG
- TCPSECURE: WGLC around Dallas, to IESG May06
- UTO: (Lars Eggert: should be Experimental track)
- soft errors/informational: WGLC around Dallas; to IESG May06
- Markku: when will 2581bis be out? Allman says: 1-2 weeks
- Lars: happy with proposed milestones
- Develop milestones for advancement to DS of important TCP specs:
2018, 2581, 2988
- Matt Mathis: 2018 & 2581 are old-style RFCs 'requesting comments';
need to move it on because it is effectively a Standard; the work
to be done is really process related, not technical
- Markku: this work should move forward; ready to work on
- Gorry Fairhurst: it needs to be done and done in tcpm. willing to read the
- Colin Perkins: need to simply write an email to IESG saying 'I tested the
protocol and it works'
- Pekka Savola: the process spec asks for fine grain testing but IESG
has been willing to accept more high level implementation reports
- Mark Allman: should be able to leverage the literature on
implementation reports but still requires energy
- William : How long a list can we create for this?
Ted: concerned about expanding beyond available effort.
William: there are many experimentals which might be worth doing.
Ted: Exp's are more work.
T: would love to see it move quick.
- RFC1323 needs submission to IESG as PS or possibly DS.
Ted: Room says this list and plan is OK
TCP User Timeout Options - Lars Eggert (NEC), Fernando Gont (UTN/FRH)
Tim Shepard (Shep): why do end points need to agree on user time out?
Lars: can't know ahead of time what the communication pattern will be?
Shep: so it isn't *required* that they coordinate.
Shep: my UTO sets my persistence, how does it help for you to know that?
Touch: it helps for bidirectional communication, where the effective
timeout is the lower bound of the two directions, so you invest buffer
space only for connections that benefit from it
Shep: I don't see any value in using the UTO option to *raise* the
value of timeout, trying to see the value of *reducing* the value
- Are we done?
Lars: Looking for folks to commit to reading the entire draft.
Touch: I'll do it.
Matt Mathis: basic semantics seem correct but the API needs work.
Needs to be able to tell the stack whether you are negotiating up or
down, lots of cases where it would be useful to negotiate this but you
need to know which way the application would prefer.
Anantha Ramaiah: what is the urgent need for this?
Lars: comes from running TCP over disrupted links, like nomadic
Anantha Ramaiah: have you checked with mobile IP groups to see if they need
Lars: still need it even without mobility
Bob Braden: seems sensible; what would Jon Postel say? The way you
treat the information from this option is application specific, so
it should be done at the application layer. Jon was opposed to
keep-alives for the same reason.
Touch: rebutting Braden. This is not a negotiation, TCP is just
communicating the information to the other end; its the application
that makes the decision on what to do.
Ted: No, you are setting a default variable; if the application
says 'I don't care', the default wins. So, it is TCP not
Shep: to Matt: Does putting something in TCP to signal this e2e help
the situation? I do believe there is a problem here, that the stack
has a hard-wired timeout option and mobile users have a problem.
TCP needs to be changed both on the mobile node and the server.
What we need is that TCP has a mechanism to change the policy on the
machine to raise the values. Suggest this is a policy negotiation
issue, not relevant to the value. WG should publish a document on
what the problem is.
Randall Stewart: I like the idea of having more control. This should be off
ICMP Attacks Against TCP - Fernando Gont (UTN/FRH)
- Mitigating the blind connection-reset attack
- Mitigating the blind throughput-reduction attack
- Mitigating the blind performance-degrading attack
- Running Code
- Issues Raised on the Mailing List
- Moving Forward
Matt Mathis: a version of this work is critically important;
original documents were just informal implementation agreements;
this document is taking current implementation processing and
writing a standard around it; the code in the field is quite a bit
different from what's in the original documents; haven't reviewed
the actual code; the key issue is that this is a standards revision
document, not a security document
Anantha Ramaiah: support this as a working group item
Touch: like the concept of this doc; but this current draft is spun
wrong; wish the doc highlighted checking checksum, window,
signature; need to be specific about not checking window when saying
Fernando: current specs don't require including full packet to
allow checking checksum and MD5 sig; *that's* the point
Touch: then why do you think you can parse a TCP header if there
is no valid checksum?
Fernando: that it's more conservative to perform as
many checks as possible on the received ICMP message (even if you
were not able to check the checksum) than to simply honor the ICMP
message without performing these checks. (It's not that it's the
best thing you could do.... but for most ICMP messages you won't be
able to check the checksum).
Ted: I like tying the hard error/soft error check to validity checks
Pekka Savola: important work and critical to IETF remaining
relevant in TCP; agree with Matt;
John Heffner: like that this document documents the current implementer
practice; may make a good Informational RFC; PTMU WG was working on
Fernando: may want to break PMTUD into two phases
Ted: sense of the room on taking on this draft as a WG item.
In favor of WG item: strong hum
Matt: another possible strategy is to completely rewrite the ICMP
processing of 1122; out of scope of this WG but is what is really
Ted: my digging shows that the material is sprinkled throughout
Gorry: an Informational is good; but should we do a protocol spec
here? [ Specifically there are 2 issues, documenting current usage
and proposals to change protocols and these may need to be
separated into 2 documents if both issues are addressed. --
clarification from Gorry ]
Joe: This will have implications on DCCP and SCTP; should
address it in a transport protocol-agnostic way; make this
document more as an Informational on what is currently done;
take the other issue to tsvwg;
Fernando: DCCP and other protocols are handling this
Ted: would like an overarching document
Touch: would volunteer to work on doc
Randall: in SCTP our strategy was to write a doc that noted all
deviations of 1122 on ICMP handling, in all cases new behavior is
Lars: in DCCP this issues has not come up yet
Aaron: actually it came up and decision was to let TCPM deal with
Ted: another hum "hum if you are in support of taking on this document
Ted: Encourage folks to work on overarching document on ICMP handling,
updating 1122 but in a WG where it is on topic, probably tsvwg.
TCP's Reaction to Soft Errors -- Fernando Gont
- WG consensus
- Moving forward
Ted: who's read it? ~3
Fernando: though the consensus was to describe implementations
Touch: would like to see more evidence that folks have read this *before* WGLC
Matt: does this need to be separate from the previous document?
Ted: yes, very different; last document was conservative, this one
is more aggressive
Matt: but both are just documenting current practices in ICMP and TCP
Pekka: goal of documents are different so should not be combined;
but a common document on TCP and ICMP protocols would cover both
Braden: too easy to create lots of documents without common view of
the field; RFC793 would be six documents if done today. Matt
articulated a common goal that would absorb both.
Authentication for TCP-based Routing and Management Protocols - Ron
- (problem statement?)
- Constraints Upon a Solution
- Proposed Solution
- Receiving Station Procedure
- Choosing Hash Algorithms
Pekka: this may be useful but IMO it is good to remember that there
may good reasons why this is not being used.
Touch: in BTNS about why folks don't turn on TCP MD5; most reports
focus on CPU utilization. Do you have any measurements on relative
weight. (no.) My previous experience is that SHA-1 is faster.
Another issue is the having the ability to negotiation the keys on the
fly. Your architecture focuses on manually keying; I see this as a
high hurdle to using this. Would be preferable to have a mid-stream
D-H negotiation than use a key chain.
Ron Bonica: much of this process came from IPsec; we assume there
are keys obtained somehow, and down the road we'll figure out how
to deal with it eventually
Touch: would like to see this addressed in *this* document. you
can't automatically key, you can't automatically re-key. should fix
in this doc.
Matt: this service is slightly above the transport layer that is
really just generic out of band data. Doesn't feel like there is a
good fit between some of the semantics of your options and the key
Chandra, cisco: today we can change MD5 keys. but you need to change
the keys on both sides before expiration of the session. So the issue
is mostly operational. Re: CPU utilization is not really relevant.
Feel MD5 is not used because it is 'a little inconvenient'.
David McGrew, Cisco, CFRG chair: great to see something other than
keyed MD5 (which is essentially broken). Should have a strong message
authentication code, current mode should be deprecated.
Ted: need to have a mandatory algorithm
Bill: look to this group for advice on which one should be mandatory
David: SHA-1 is facing deprecation from NIST
Touch: CPU utilization: SHA-1 is a lot worse than MD5; not clear
attacks are valid over the lifetime of the keys; prefer two mandatory
algorithms: one strong algorithm and one (weak) fast one.
Randall: do you mention NTP?
Bill: nope, no assumption on clocks
Randall: if someone can scam your NTP they can adjust your time so
two people can't talk since they would be on different keys
Bill: this is why tolerance is a parameter
Chandra: Key rollover and algorithm are independent and different
problems. We have draft on solving key rollover.
Shep: are the mandatory pieces going to be mandatory parts of *TCP*?
Ted: no, just as part of this option
Pekka: would like to understand the goal here? Is this a
standards-track thing? The proposal is probably insufficiently secure
to be accepted by the IETF security community. Perhaps just want to
document it as informational or experimental.
Touch: biggest problem would be to call it the "TCP MD5 Option",
calling it the TCP Security option would be more likely to succeed.
need to address whether keying is inside the system or using IKE or
what. Not clear to me that this should NOT become standards track.
Well, a standard option.
Anantha Ramaiah: Issues I raised on the list need to be addressed, too.
Ted: sense of the room.
Touch: wondering what the security communities reaction is? Suggest
taking the proposal to SAAG.
Chandra: would like to see more written
Al Morten, The Deathstar: this is an area of exposure, need to have
this fixed soon. Well studied is better than hasty.
Shep: agree with Touch. TCPM probably isn't the right place to
evaluate the security properties.
Chandra: what is the question for SAAG?
Shep: SAAG needs to have a higher level discussion on how to solve
Touch: Q: should we waste our time trying to fix the TCP security
Ted: have people read this? ~5
The TCP ESTATS MIB - Matt Mathis, PSC
- TCP ESTATS MIB
- Implementation Status
- Plans Forward