To: tcpm@ietf.org
From: Mark Allman <mallman@icir.org>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: And We Danced
MIME-Version: 1.0
Date: Wed, 02 Jan 2008 14:06:37 -0500
Message-Id: <20080102190637.547C93263F1@lawyers.icir.org>
Subject: [tcpm] Matthew J Zekauskas: TCPM minutes, IETF70, edited version
Precedence: list
Reply-To: mallman@icir.org
Content-Type: multipart/mixed; boundary="===============1496189814=="
Errors-To: tcpm-bounces@ietf.org

--===============1496189814==
Content-Type: multipart/signed; boundary="==_bOundary";
 micalg=pgp-sha1; protocol="application/pgp-signature"

--==_bOundary
Content-Type: multipart/mixed; boundary="=_bOundary"

--=_bOundary
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


Matt sent these to us, but then noted he should have copied the list.
Please send corrections soon.  The final version is due Friday, I
believe.

allman





--=_bOundary
Content-Type: message/rfc822; charset=us-ascii
Content-Disposition: attachment; filename=10781
Content-Description: forwarded message

Replied: Wed, 02 Jan 2008 13:59:59 -0500
Replied: "Matthew J Zekauskas <matt@internet2.edu> "
Return-Path: matt@internet2.edu
Delivery-Date: Wed Jan  2 12:56:45 2008
Return-Path: <matt@internet2.edu>
X-Original-To: mallman@localhost
Delivered-To: mallman@localhost.icir.org
Received: from guns.icir.org (localhost [127.0.0.1])
	by guns.icir.org (Postfix) with ESMTP id 4B42713B3E88
	for <mallman@localhost>; Wed,  2 Jan 2008 12:56:45 -0500 (EST)
Received: from mailhost.icsi.berkeley.edu [192.150.186.11]
	by guns.icir.org with IMAP (fetchmail-6.3.8)
	for <mallman@localhost> (single-drop);
	Wed, 02 Jan 2008 12:56:45 -0500 (EST)
Received: from pork.ICSI.Berkeley.EDU (pork [192.150.186.19])
	by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id
	m02HuBfY029945
	for <mallman@icsi.berkeley.edu>; Wed, 2 Jan 2008 09:56:11 -0800 (PST)
Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22])
	by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id
	m02HuAWA016880 for <mallman@icir.org>; Wed, 2 Jan 2008 09:56:10 -0800
Received: from localhost (localhost [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id BA7B047C6D; Wed,  2 Jan 2008 12:56:08 -0500 (EST)
Received: from basie.internet2.edu ([127.0.0.1])
	by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 04615-08; Wed,  2 Jan 2008 12:56:08 -0500 (EST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by basie.internet2.edu (Postfix) with ESMTP
	id 0FCED47C32; Wed,  2 Jan 2008 12:56:08 -0500 (EST)
Message-ID: <477BD036.5070208@internet2.edu>
Date: Wed, 02 Jan 2008 12:56:06 -0500
From: Matthew J Zekauskas <matt@internet2.edu>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Mark Allman <mallman@icir.org>, Ted Faber <faber@ISI.EDU>
Cc: Matt Zekauskas <matt@internet2.edu>, Joe Touch <touch@ISI.EDU>
Subject: TCPM minutes, IETF70, edited version
X-Enigmail-Version: 0.95.5
Content-Type: multipart/mixed; boundary="------------020407040304070003060209"
X-Virus-Scanned: by mail.internet2.edu virus scanner
X-ClamAV: OK
X-SpamProbe: GOOD 0.0000097 e09de7c0aedab0143727a18e4ad60490
X-mallman-sequence: mallman

This is a multi-part message in MIME format.
--------------020407040304070003060209
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Here's a version of the TCPM minutes I think is suitable for posting,
and getting general comments...

I've attached it as text.

Joe: the audio cut out on the discussion that begins "There was a
question about the use of option types" -- I'm not sure fully caught the
gist of the discussion, so you might want to review it.  Actually, I'll
duplicate it here:

  There was a question about the use of option types.  Joe said we could
  use a single option type, which the security association would encode
  (if you didn't have the right algorithm, you could not verify the
  stream).  The reason for multiple option types is that it is clear
  when we change the MAC; it's really mostly for the human beings, so
  that they note we are switching to something completely different.
  Sandy noted that it's also easier for humans to write the
  implementation.  Joe said that it wasn't strictly necessary, though.
  We are not going to use the MD5 hash as a viable algorithm for
  TCP-AUTH.  Thus, the hash would never generate a result that would
  collide with something else.


Thanks,

--Matt

--------------020407040304070003060209
Content-Type: text/plain;
 name="tcpm-minutes-02.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="tcpm-minutes-02.txt"

TCP Maintenance and Minor Extensions WG (TCPM)
Tuesday, 2007-12-04, 17:40-19:50, Salon 2
IETF-70, Vancouver, BC, CA
===============================================

This session was "guest chaired" by David Borman and Lars Eggert.  The
chairs, Mark Allman and Ted Faber, listened to audio and were on the
Jabber session.  Matt Zekauskas acted as scribe.

AGENDA:
1.  WG Status + Agenda bashing (10min)
2.  UTO scraps (10min)
3.  ECN-SYN WGLC (5-10min)
4.  Advancing F-RTO (10min)
5.  Acknowledgment Congestion Control (10min)
6.  TCP Authentication Option




1.  WG Status + Agenda bashing (10min)

(see slides)

Lars opened up the meeting.  There are two working group last calls
underway: 2581bis and ECN-SYN, which run until 21-Dec-2007.  Please
comment.

Tcpsecure has been delayed waiting for an applicability  statement by 
the authors for discussion in the working group.  The statement should 
indicate which mechanisms that the document proposes are suggested to
be implemented by TCP (or which TCP implementations should consider
implementing the proposed remedies).

The TCP-AUTH design team has finished.  They have come up with an
initial proposal to obsolete TCP-MD5.  The team has been running for 6 to 9
months; the working group now takes over.  (This is the subject of the
last agenda item.)  The draft is pretty solid.  There are a few remaining
issues, but nothing large.  We expect to move it quickly through the
working group.  Work has been started outside TCPM for algorithms
and keying components.  There will be a discussion in the security area
group (SAAG) later this week.





2.  UTO scraps (10min)
    draft-ietf-tcpm-tcp-uto-08.txt
    -- Lars Eggert

There were no slides for this item, as Lars just wanted to call
attention to the current state.  This draft is in working group last
call.  There has been a revision posted that Fernando and Lars believe
addresses all comments.  If you commented, please check and see if you
agree.  If there are no further comments we will end WGLC.  Magnus
will be acting as AD for this draft, since Lars is an author.




3.  ECN-SYN WGLC (5-10min)
    draft-ietf-tcpm-ecnsyn-03.txt
    -- Sally Floyd

This draft, too, is in WGLC.  See Sally's slides for a summary.

One issue that was left open for a year was how to respond when a
SYN/ACK is marked with ECN.  Should we decrement the congestion window
immediately or wait one RTT.  They finally did some simulations,
which was reported on at the last IETF.  The current version addressed
issues in raised in the meeting.

There was also some general editing.

There is one open question from WGLC comments.  This was raised by Bob
Briscoe (who showed up while this point was being made during this
meeting).  In Section 4, there is a subsection on backwards
compatibility.  Old (current) implementations (Linux, Windows (which
is not enabled by default), Mac OSX (again not enabled by default))
ignore the ECN mark, which is what the current standards say.  The
problem is if the originator, who sends the SYN, doesn't understand
ECN marked SYN/ACK, with a new responder -- and the SYN/ACK is marked
in the network.  Does the originator ignore the marking or tell the
other end point.  Current implementations will ignore.  A new
implementation will "do the right thing".  The draft did not add
negotiating capability... this is a transient backwards compatibility
problem.  The authors felt it was not so terrible; few are using it
now, and if the sender doesn't hear about it; the sender will hear
eventually on data.  This seemed a "ok to live with" problem.  Bob
disagreed during WGLC.

What do you do?  One could use one of 4 reserved flags left in the TCP
header.  The flag would be only meaningful in SYN. [option 2 on slide]
One could use an ECN-SYN option, but Sally did not think that would be
a good idea.  So, Sally would be happy going with the reserved flag
(since it is only meaningful in SYN, and could be reused later) or
ignore [option 1 on slide].  What did the group think?

During Sally's explanation, Bob arrived, and commented that he would
generally be happy with 1 (ignoring the problem), but felt we should
better understand the problem before deciding.  He could see problems
with short flows.  He was not as happy with using one of the reserved
flags for this transient condition.

Gorry Fairhurst asked Bob to clarify the bad situation -- is it when
the whole transaction is just 4 packets?  Sally replied first, saying
yes, that's that's the bad situation, if servers are old and marking
the SYNs, and there are lots of short transactions.  This could be
unfair with respect to others that did not use the ECN marking.  If
the endpoints that use ECN have all their packets get through, and
those that don't have their SYN/ACK packets dropped, and thus timeout.

Bob stated that a quick back of the envelope calculation showed that
something like 70% of objects are served in one initial window.  If
the SYN/ACK is ECN marked and the receiver does not understand, then
the sender never responds to congestion, and this is bad if there are
a large number of flows.

Mark Allman commented that the cost to solving the problem is too
high.  Sally remarked that she didn't think it warranted study for
another year.  David Borman noted that if you choose option two (an
additional TCP flag) you are stuck with it forever.  If you ignore the
problem, it goes away once the transition is over.  Unless severe
problems crop up, thinks ignoring the problem is the right way to go.

Sally commented that it is easier to upgrade web servers than users,
and web servers that could be problem.  Bob disagreed, in that the
upgraded web server with lots of stupid old clients is where the
problem comes up (since it's marking the SYN/ACK).  Sally agreed, and
said one factor in favor is that the old behavior is not enabled by
default.  If this comes out after a large release that enables it,
then we might have a problem.

Lars stated that he's leaving it to the real chairs to declare
consensus: please discuss on the list.





4.  Advancing F-RTO (10min)
    draft-ietf-tcpm-rfc4138bis-01.txt
    draft-kojo-tcpm-frto-eval-01.txt

Markku Kojo presented the case for advancing F-RTO to proposed standard
from experimental.  See slides for background.

The revised draft added back enhanced SACK, which was removed in -00,
because the authors discovered that most implementations do use it.
There is also a clarification of multiple timeout behavior.

The main question to this group: is it ready to advance?  The authors
think there are strong arguments for advancing the specification;
there is a wide base of independent interoperable implementations.

Lars noted F-RTO has been experimental for a long time; there is a
desire to move it to proposed standard.  There are lots of implementations.
He wanted to get a sense of the room if people supported advancing the draft.

Sally noted that she has not followed it in great deal lately, but it
seemed reasonable to her.

Lars said his personal take was that there is a very strong show of
support for this, given the number of implementations that use it by
default.  In his opinion it has already passed the bar for full standard,
and it should be easy to go forward.

Mark Allman thought personally it should have gone to proposed standard
to begin with.  Ted agreed.

Please comment on the list.






5.  Acknowledgment Congestion Control (10min)
    draft-floyd-tcpm-ackcc-02.txt
    --Sally Floyd.


Sally presented acknowledgment congestion control, which is something
she has been working on.  It is "mostly specified"; there have not yet
been any simulations.  The question here is if it looked like a
reasonable item for the working group to take on, targeted for
experimental.

There is one slide on what's there; basically if there are lots of lost
ACK packets, use a higher ACK ratio.  The sender uses byte counting and
rate-based pacing.  There are lots of changes from the last revision.
The use of SACK will change from REQUIRED to SHOULD, most likely.

The big possible complication is what happens if TCP skips sending some
ACK packets, or a middle-box suppresses some of them.  There are many
proposed mechanisms, but it is not clear if any have been implemented.
the problem is that if ACKS are skipped, the sender doesn't know if
they were dropped or not sent.  What can we do?

  1.  receiver could say, I will not skip ACKs if using ACKCC
  2.  receiver could use a TCP flag to tell the sender that it
      is sending aggregated ACKs.  Sally noted that she was
      not asking for a flag today.

Simulations and other evaluation will start in January.

Sally asked if there were any comments... did the group feel if
this was baked enough for the group to take on as an experimental
specification?  And if so, what kind of experimental -- how cautious
should we be in the advice to implementors paragraph in the abstract.
That really would have to wait for the evaluation.

Lars asked who had read -- a couple, one of which was the co-author.

Gorry asked if he could ask a question without reading -- how does
this draft relate to RFC 3449 from PILC, relating to asymmetry.

Sally said that she thought she looked at it (a document by 
Hari Balakrishnan over lunch; that document cited a bunch of proposals
and related work. This document could be thought of as a successor to
that one, and cites it.  Hari had his own proposal that wasn't so much
highlighted by that draft/FRC; it was presented in an earlier paper.
In that proposal, all ACKs were ECN capable, and the sender and the
sender would detect the loss of an ACK packet because it was ECN
marked; it wasn't trying to detect dropped ACK packets. The proposal
in this document is more general and robust than that one.

Gorry said he was thinking more about the case in 3449 where
middleboxes were considered. (There was some confusion if Gorry and
Sally were talking about the same document or not; I believe Gorry
thought so.) What happens if they reduce ACK rates?  Sally didn't know
off-hand, but it was one of the things that Hari's draft talked about
(using middleboxes to reduce ACK frequency); she thought this draft's 
technique should be much better.

Mark Allman commented that there was work in TCPSAT on this issue as well.

Over the next few weeks Sally wants to hear on the mailing list if
this draft should become a working group document.




6.  TCPM Authentication Option
    draft-ietf-tcpm-tcp-auth-opt-00.txt
    --Joe Touch

Joe Touch explained the input, a bit of process, and the results of
the design team looking at TCP MD5 replacement options.  As input were
the candidate drafts for updating TCP MD5, and a draft from Steven Bellovin
on the security requirements for a TCP MD5 replacement.

The output is the current TCPM I-D.  As part of the work, however,
the group updated and augmented Bellovin's requirement document.
The new list is summarized and addressed in the TCPM I-D.  One
question for the group would be should we move forward with two
documents (the TCP Authentication Option document, and a requirements
document) or just one.

Joe also summarized the key decisions of the team (see slides):

* Use a new option type, as it is both safer and easier.  A "Key ID"
  is available for use during long-running connections to easily allow
  rekeying.  It is optional, and intended to be used for the short
  period where there could be key overlap.

* Do not directly support NATs, as they do what this option is designed
   to detect.  If you must use a NAT, tunnel TCP over another transport
   protocol -- which is what IPsec does.

* It is optional to say if TCP Options are authenticated.  There are
  various boxes that munge them, and you may want to detect this (it
  is again in some sense the attack that TCP AO is designed to detect).
  However, there may be cases where it is desirable to disable them.
  This is another place where the group needs to make a recommendation
  on how to go forward.

* 8 bits of key space should be more than enough to support all the
  keys a single connection needs at a given time.

* The draft does not specify which algorithms should be used.  That's for
  the security area, which has the expertise, to help us with.  We just
  want two that are mandatory to implement, so there is backup if one
  is cracked.

* Authenticate before TCP processing.  The temptation is to be able to
  drop a packet early.  However, it is possible that any packet you
  process might update a TCP action -- like reseting a timer or duplicate
  acknowledgment processing... so you need to check the validity before
  processing.

* The draft is agnostic with respect to key management.  There
  should be some external key management solution.

* You cannot start a connection with TCP-MD5 and then switch to something
  else.  The existing TCP-MD5 specification does not allow it.

  However, the new TCP AO system could include support for MD5 for
  backward compatibility.  [The draft currently recommends this.]

The group decided to start with draft-touch-tcp-simple-auth and
modify that, since it required the least amount of changes to
match the requirements.  It was updated to reflect the key decisions
above, and address Steve Bellovin's issues.  It has a TCP Security
Association Database (TSAD) like SAD in IKE.

Joe then went on to show a summary of the proposed algorithm,
including some packet headers (see slides).

There were some things the design team deliberately left out.

* In-band key negotiation.  The TCP header space is not big enough
  during the initial three way handshake.

* Replay protection.  TCP provides that in the transport layer.
  Between sessions, don't re-use the key; this is an additional
  requirement.  Use IPsec if you want to maintain keys.

* Key synchronization.  You don't want to deal with packet reordering
  or anything else, so the KeyID was introduced to allow you to choose
  the right key during rollover.

Paul Hoffman asked a question about re-use of keys.  He remembers
a discussion, perhaps in Dallas, where a desired use case is that
people use passwords.  Here you couldn't use the same password twice?
Joe replied that in that case, the password would not be the sole
input to the session key.  This is part of key management; even
with manual keying, you don't re-use per-session keys.
Paul asked that in the case of a password, you would not just
use something read over the phone; Joe replied again that there
are techniques to generate a good session key, and he thinks
we can do that.

What do you lose if you do allow reuse?  You are encouraging
use for long periods; you could have an attacker take some
material from an old connection and put it in a new one.
Paul understood that it was "bad hygiene".  Joe said that
non-re-use is a SHOULD in the current document; they were
thinking of allowing explicit overrides for some cases.

Paul said he was worried that it's not necessarily clear
when the session changes.  Joe noted that if you have a TCP
session, an endpoint can go away and return, and TCP would continue
to accept data with the same key.  In any case where the connection
closes or aborts or restarts, the connection should have gone into
time-wait, and it should be noticeable, and yes that's when you would
use a new key.  If that is not clear in the document, it could be
improved.

Ted commented on Jabber that the term session is misleading.  Joe
means TCP connection lifetime which is well defined.

There was a comment that replay was the only issue; any of the new MACs
is strong enough to run for a long time.

So, the next step is to get feedback from TCPM.  Section 1.3 has the
open questions list.  Please ignore for now errors in the table of contents
and numerous typos.  In addition, there is a joint discussion this week
in SAAG on key management and algorithms for TCP-AO.  Please participate
there.

Sandy Murphy said that there was at least one point in the document
where it states that key re-use MUST be prohibited.  Given the
several comments here, and the comments in the design team on
key re-use, Sandy expected this was an area that needs some attention
by the working group.  If there is replay possibilities between
the same source and destination, one of the ports should change.
Joe noted that after time wait, TCP can re-use ports, however.
One of the most dangerous attacks has to do with injected SYN packets;
if it is accepted, it will abort the connection.

Lars noted that the algorithms will be discussed in the Security area
(SAAG) on Thursday.  It would be good to get input from SAAG on keying --
understand if the document is going in the right direction, or is completely
wrong.  Please read and comment.

Lars called for a two part question for the room -- to get a feel for
the room, not deciding anything.  Hum if you think that modulo some
fixes and clarification this document is what eventually will be put
forward as a replacement for TCP MD5.  [high-moderate hum]

If you don't think this is the right base, and would like something
else [no discernible hum].

Lars felt that this was a strong indication that this document is
a TCP MD5 replacement candidate.

Paul asked for clarification on what SAAG would do regarding
helping with key management and MACs.  Joe said that the design
team felt that there was little expertise here, and we should
request input from where the expertise was -- SAAG.  There didn't
seem to be a particular working group that fit, so considering
it in SAAG and TCPM seems to be the right choice.  As long as
two authentication algorithms are recommended, that would be
fine.  We would also like them to be reasonably fast.

A question was relayed from Jabber: Ananth asked why does
the document specify that it obsoletes 2385, but it still allows
co-existence with 2385?  Ted Faber stated that he thought it would
obsolete 2385; Ananth clarified that it allows MD5 to continue to
exist, though.  The document is intended to be backward compatible.

Sandy asked if it is an "obsoletion" if we are proposing that the two
might work at the same time?  The RFC editor allows only a small subset
of verbs.  "Obsolete" is the only one that fits.  It is not updating,
and it is not deprecating.  Paul noted that "obsoleting" means deprecating
the old document immediately.  Joe noted that it should be deprecated for
a number of security reason.  Paul clarified that it means deprecating on
the day the new document is published.

Paul thought that this is similar to a discussion he had about SMIME;
we shouldn't say obsolete.  The right thing to do is not obsolete
the document, but have a separate document to deprecate or make historic
or obsolete TCP MD5.  When that one passes, TCP MD5 will fall off the
acceptable stack.

Lars felt that Paul was right with respect to the verbs.  Paul said
that when something says deprecate, it means "change status to
obsolete".  Joe said that the design team intended to make the old
version obsolete, but not completely prohibit to support legacy code.

Tero Kivinen thought we should look at IPSEC as an example. IKE2
obsoleted IKE1, yet most everyone continues to use IKE1.  There are
even RFCs out after IKE1 was obsoleted, supporting and adding stuff to
IKE1.

The working group should get a better indication of what the names mean,
and indicate which one we would like to use.

There was a question about the use of option types.  Joe said we could
use a single option type, which the security association would encode
(if you didn't have the right algorithm, you could not verify the
stream).  The reason for multiple option types is that it is clear
when we change the MAC; it's really mostly for the human beings, so
that they note we are switching to something completely different.
Sandy noted that it's also easier for humans to write the
implementation.  Joe said that it wasn't strictly necessary, though.
We are not going to use the MD5 hash as a viable algorithm for
TCP-AUTH.  Thus, the hash would never generate a result that would
collide with something else. 

Lars noted that TCPM probably doesn't have strongest feelings about the
continued use of MD5; it is the security folks that should have the
most input with respect to what should happen with MD5.  We should
take their input and go along with that.

Lars then went back to fact that the document currently contains two
parts; the TCP-AUTH protocol, and the requirements that are an
extension of Steve Bellovin's document.  Should this be one document
or two?  There was a general feeling that we should do whatever makes
the document come out faster.

Gregory Lebovitz recommended two documents.  Brian Weis felt that two
documents would be both faster and clearer in the end.  Joe argued for
one, feeling that there was less for people to go read.  Mark Allman
felt that we should have one document unless there was a compelling reason
for two, and they are somewhat combined right now.  Gregory was not opposed
to one document, but felt both would move faster than one.

There was a short discussion on list of requirements.  We could change
the requirement that we MUST single key.  There are a few more things
along the same lines in the document; the design team made some
decisions, but if the working group wanted to change them, it could do
so.  Gregory said that he hasn't read the latest on the requirements,
but were all of Ron Bonica's concerns with BGP addressed?  Joe said
those requirements are for keying, not authentication.  The keying
issues will be considered in SAAG or a spinoff; but it is a real
concern -- how fast can you generate keys.

With that, Lars closed the meeting.

--------------020407040304070003060209--

--=_bOundary--

--==_bOundary
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHe+C9WyrrWs4yIs4RAhYeAJ9yMN2+miugGPyZg/mBsiQM7BNkQwCfeQbH
EN/xJ3/rfcqBtj+yHn6O2FY=
=A+fy
-----END PGP SIGNATURE-----
--==_bOundary--



--===============1496189814==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm

--===============1496189814==--