Security Assessment of the Transmission Control Protocol (TCP)

Fernando Gont fernando at gont.com.ar
Fri Feb 13 16:39:49 CST 2009


Barry Shein wrote:

> And it was observed that routing around damage could at least in
> theory have utility in a situation where circuit facilities were being
> damaged in warfare so long as some route between two points remained.
> 
> So these two goals are not mutually exclusive by any means.

The point of the text was to point out that "operating in warfare
environments" was not the top level goal. The recent John Day¿s
"Patterns in Network Architecture" provides more insights in this aspec.



>> As a result, many protocol specifications focus
>> only on the operational aspects of the protocols they specify, and
>> overlook their security implications.
> 
> This is a non-sequitar and not a result at all. Neither goal implied
> security, only integrity.
> 
> This was not an oversight, security was, and to a great extent still
> is, thought to be a higher-level function than packetizing and packet
> routing, with a few exceptions where a potential security flaw truly
> lies in the protocol (e.g., poor choice of packet sequence numbers.)

I don't really understand what you mean. Attacks such as syn-floods and
others are clearly issues that lie in the protocol design. And while it
is understood that security was not a goal two or three decades ago, one
would expect that it should be a goal nowadays, and that the specs
should have been updated accordingly.



>> For some reason, much of the effort of the security community on the
>> Internet protocols did not result in official documents (RFCs) being
>> issued by the IETF (Internet Engineering Task Force).
> 
> (for some reason?)
> 
> To the best of my knowledge the reason is quite simple: That is not
> what RFCs are used for tho occasionally some summary of the state of
> the art appears in an RFC.

Not sure what you mean.

Only *few* years ago there was some work published within the IETF about
well-known issues such as, e.g., syn-floods.

Think about any TCP/IP-based security issue, and most likely you will
not be able to find any information about it within the RFC series.

Talk with anybody that works day-to-day implementing the TCP/IP
protocols, and most likely the comment you'll get about the current
situation is a PITA.

A few years ago I published an I-D on ICMP attacks against TCP
(draft-ietf-tcpm-icmp-attacks, which is close to be published as an RFC,
I believe). Known issues... but the counter-measures were not clear. The
reult? 	Vulnerability advisories from many vendors, including Cisco,
Microsoft, and the security-concious OpenBSD.

I don't think it should be that hard to implement the protocols in a
security-conscious way from the IETF specs. And that is the area in
which this CPNI document (and the preivous "Security Assessment of the
Internet Protocol") tries to help.

Kind regards,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1








More information about the NANOG mailing list