Subject: [tcpm] tcpsecure: when to expect draft-01?

From: "Charlet, Ricky" <[email-masked]>
Date: Wed, 19 May 2004 16:58:45 -0700

Howdy,

	I'm trying to implement draft-ietf-tcpm-tcpsecure-00.txt. There
have been criticism on the list and seemingly, the working group is
taking some of them to heart. Also, there have been suggestions that a
next draft is imminent.

	Can someone offer prognostications about when draft-01 will be
published and at what points it may vary from draft-00?

Thanks in advance

---
Ricky Charlet
[email-masked]
USA 831.466.4968

-----------------------------------------------------------
Unless otherwise expressly stated, this message does not
create or vary any contractual relationship between you and 
ARC International.  The contents of this e-mail may be 
confidential and if you have received it in error, please 
delete it from your system, destroy any hard copies and 
telephone the above number.  Incoming emails to ARC may be 
subject to monitoring other than by the addressee.

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 19 May 2004 21:33:52 -0400

Ricky:

I can't give you an exact date... but I can give
you a ball park... I am waiting on inputs from a
couple of the co-authors.. and I just got one more
to-do from the list (above)...

Sooo... I would hope to get something out by
the end of next week..  sigh..

R

-- 
Randall R. Stewart
ITD - Transport Technologies
815-477-2127(o) or 815-342-5222(c)

---

From: Mitesh Dalal <[email-masked]>
Date: Wed, 19 May 2004 20:31:48 -0700 (PDT)

sorry for the delay in the second draft. We are trying to
find more information to put into the draft that should
hopefully satisfy the WG. To answer the second part
of your earlier question, the second draft should cover:

1. alternate solutions that are known today: MD5, IPSec,
port randomization. This will only be quoted for purpose
of reference and not to make a suggestion as such as
some folks have pointed out that MD5 was intended for BGP
and is not generic enough.

2. Correct typos.
a. in the SYN section from RCV.NXT == SEG.SEQ to RCV.NXT -1 == SEG.SEQ
b. in 4.2, a missing = as pointed yesterday.

3. An appendix describing scenarios where the proposal
might not work.
a. middleboxes that cache RST.
b. middleboxes that compute RST to be at the higher
end of the rcv.wnd.
c. RST/ACK war for dropped/delayed packets.

4. More explanantion of scenarios that make the solution
to likely happen with todays implementations.

Anything else the WG would like to see being added
to the draft ?

thx
Mitesh

---

From: Anantha Ramaiah <[email-masked]>
Date: Wed, 19 May 2004 23:21:42 -0700 (PDT)

Mitesh,

> port randomization. This will only be quoted for purpose

Do you want to tag some of these as "alternate solutions".?
I would just mention these are alternate methods which can
be used to alleviate these type of attacks with varying degrees,
merits and demerits.. (briefly) All I am pointing out is the
current proposal should be viewed as doing whatever possible with
less changes for making TCP protocol robust to these type of attacks
in a standalone manner.

> c. RST/ACK war for dropped/delayed packets.

What is the general rule of thumb for any TCP extension written today?
Should it strive for compliance with middle boxes? probably not.
May be we can just mention some scenarios where the solution is likely
to have some issues?

-Anantha

---

From: Florian Weimer <[email-masked]>
Date: Thu, 20 May 2004 12:30:35 +0200

> and is not generic enough.

IPsec without ISAKMP, please.  ISAKMP is probably not robust enough
(think of all the recent DoS attacks).

> Anything else the WG would like to see being added

At the minimum, a rate limit for the new ACKs is required (i.e. MUST,
not MAY).  Mentioning this risk in some appendix isn't enough.

However, I still believe that the proposal is fundamentally flawed
because it does nothing to prevent other forms of blind injection
attacks.  For just one or two aspects of the issue, it's not really
worth the trouble, IMHO.

There were some proposals that the draft should not proceed as a WG
draft.  What has happened to that discussion?

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: bigpond.com, di-ve.com, hotmail.com, jumpy.it,
libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com,
tatanova.com, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com.

---

From: Mitesh Dalal <[email-masked]>
Date: Thu, 20 May 2004 11:55:45 -0700 (PDT)

> not MAY).  Mentioning this risk in some appendix isn't enough.

this will depend on the implementors paranoia. Adding a rate limit
simply introduces more state and logic into the code and is prone
to error. As we have been saying, please bring forward a valid scenario
where an ACK war might happen. All scenarios brought forward are simply
offending middleboxes which need to be fixed. And from the mails
on the WG, the WG itself seem to be divided on this issue. Some
folks supporting to account for such a middlebox in the solution and
the others supporting to fix the middlebox. So the right think to do
it seems is to jot it down and let the implementor make a call.

> because it does nothing to prevent other forms of blind injection

do you have specific attacks in mind that are on the lines of the
problem in this draft ?

> attacks.  For just one or two aspects of the issue, it's not really

changes are always incremental. It would be difficult to identify all
holes in a single shot and fix them. But if anybody in the WG feels
that there are more scenarios which can be included in the solution
please bring it forward.

thx
Mitesh