Subject: RE: [tcpm] new work item: TCP security issue

From: [email-masked]
Date: Wed, 21 Apr 2004 06:18:31 +0300

Hi all,

> Just announced internet-draft:
> >  Title           : Transmission Control Protocol security 
> considerations
> >  Author(s)       : R. Stewart
> >  Filename        : draft-ietf-tcpm-tcpsecure-00.txt
> >  Pages           : 10
> >  Date            : 2004-4-20
> >  
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt

I support this being a working group document.  However, rather than
worrying
about the name of the draft, I would imagine that getting comments /
feedback on the draft is the more important part.  Do the chairs plan
to try to get feedback on the draft and progress the draft rather
quickly?

John

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

---

From: Mark Allman <[email-masked]>
Date: Wed, 21 Apr 2004 00:05:38 -0400

> worrying about the name of the draft, I would imagine that getting
> comments / feedback on the draft is the more important part.  Do the
> chairs plan to try to get feedback on the draft and progress the draft
> rather quickly?

We welcome technical comments.  We are always interested in timely
comments.  But, we do not have an apriori timeline that we have not
revealed.  As sketched in my first note today we are not pre-supposing
that the ideas in the draft are even the best fixes.  If everyone could
read the drafts and send their comments to the list, that'd be great!

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 21 Apr 2004 11:05:44 +0100

Most of the mitigating techniques seem to boil down to
increasing the search space for an attacker.  To do that
and better support LFN's - why not just use a longer
sequence number field?

Since back-compatibility is vital, this would need to be
a TCP option.  Is 64 bits enough or would we go direct
to 128?

- Jeremy

---

From: Florian Weimer <[email-masked]>
Date: Wed, 21 Apr 2004 13:22:41 +0200

> and better support LFN's - why not just use a longer

Wouldn't be a cookie that doesn't change during the connection be
somewhat better?

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk,
tiscali.cz, tiscali.it, voila.fr.

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 21 Apr 2004 13:28:54 +0100

> Wouldn't be a cookie that doesn't change during the connection be

I'm assuming that performance on LFNs would be better supported by
big windows, in turn requiring big sequence space.
- Jeremy

---

From: Mark Allman <[email-masked]>
Date: Wed, 21 Apr 2004 10:26:45 -0400

> Wouldn't be a cookie that doesn't change during the connection be

Sometimes resets cross connections.  I.e., think of my long-running and
yet idle ssh connection to some remote machine.  If the remote machine
reboots while I am idle then the next time I try to use the connection
I'll get a reset.  But, the remote machine won't have this "cookie"
anymore because all the state about the connection is gone.  

allman

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 21 Apr 2004 10:12:29 -0500

Yes please :-D

R

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

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 21 Apr 2004 10:14:28 -0500

>anymore because all the state about the connection is gone.  
Mark:

One would have to treat this situation (assuming we went with
a cookie.. or has we call it in SCTP a v-tag) like SCTP does...

i.e. you would need to have a bit to indicate that its "your tag"
not the one I normally sent...

R

---

From: Mark Allman <[email-masked]>
Date: Wed, 21 Apr 2004 11:42:44 -0400

> not the one I normally sent...

I'm not the sharpest tool so you're going to have to be a bit more
verbose... because I cannot parse the above at all.

Thanks,
allman

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 21 Apr 2004 10:56:16 -0500

>verbose... because I cannot parse the above at all.
No its probably me..

In SCTP we do  at setup
E-A                                    E-Z
------                                   -------
INIT(itag=X)---------------------->
<-----------INIT-ACK(itag=Y)----

Now every packet must have the expected tag

------vtag=Y,DATA---------------->
or
<----------vtag=X,DATA-------

So E-Z always expects to se the tag Y and
E-A always expects to see the tag X in any packet.

However.. if say one endpoint restarts.. lets say E-Z.

When E-A sends a packet

------------vtag=Y,DATA---------->

E-Z wants to reset it... so it sends

<----------vtag=Y,ABORT(SPECIAL-Flag)
if it does not have the v-tag (which it would not in
a restart case).

If it did have the vtag (had not destroyed the TCB) it would
send

<----------vtag=X,ABORT

So:

1) We always send the tag of the peer, if known.
2) In the few corner cases where we don't know the
    peers tag and are sending a reset or such in response
    to a packet, we set a special flag and send the tag that
    was in the packet that caused us to send the response
    packet..

Is that better???

R

---

From: Mark Allman <[email-masked]>
Date: Thu, 22 Apr 2004 09:19:19 -0400

>     was in the packet that caused us to send the response

Yep, I understand now.  Thanks for the more detailed explanation.

I agree that this would fix the current problem.  I am not sure I think
the wasted space in every packet is worth it, since there are
alternatives that seem reasonable.  But, it is certainly part of the
design space.

Thanks!

allman

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 22 Apr 2004 12:40:41 -0700

> alternatives that seem reasonable.  But, it is certainly part of the

Or can we use the timestamp option somehow?  It should be used
when large window is used anyway.  So it is there.  On page 18
of RFC 1323, it is recommended that timestamp should not be used
in a RST.  If we think about how it can be used, maybe this can
solve the current problem without changing the basic TCP spec
or introducing new option.

Dave, do you have comments on the feasibility of using timestamp
option for this purpose?

-- 

						K. Poon.
						[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 22 Apr 2004 18:42:17 -0700

A follow up on the timestamp suggestion.  Since most TCP
stacks ignore the timestamp option if RST bit is set,
following the suggestion in RFC 1323, including timestamp
option in RST should not cause compatibility issue.

If timestamp is included in RST, a TCP receiver A can
choose to verify that the validity of the timestamp
and/or timestamp echo.  If the RST is triggered by a
segment sent by the receiver A, it should be possible to
include both valid timestamp and timestamp echo info.
If the RST is generated by the sender B when the app
aborts the connection, it should also contain the
valid info for A to accept the RST.

With this and a TCP socket option for an app to tell the
stack to have a "strict" timestamp enforcement, will this
solve the issues described in the draft?  If the TCP option
is not set, TCP's behavior does not change.  Comments?

-- 

						K. Poon.
						[email-masked]

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 23 Apr 2004 08:25:49 -0400

Kacheong:

I don't see this has any more or any less work to whats
in the draft... if I remember from my BSD coding of this it
takes about 10 or so lines of code to do the things in the
draft... I would think the T-S option would also take the same
or maybe a bit more...

And I think you probably will need to do a lot more in firewalls which
currently ignore timestamps (I would imagine).

R

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 23 Apr 2004 13:19:05 -0700

> draft... I would think the T-S option would also take the same

Actually it is not about amount of code changes in TCP implementation.
It is about backward compatibility and the probability of causing
problems.

If we think about it, timestamp echo can also be seen as a "cookie."
If we are thinking about using cookie as a solution, I guess the
timestamp option should be investigated.  And as the issue is related
to the window size and timestamp option has to be used for large
window anyway, having a "strict" timestamp test should not cause
any packet overhead.

IMHO, it is much safer to go this route than modifying the very
basic things in TCP.  Anyway, just my $0.02...

-- 

						K. Poon.
						[email-masked]