Subject: [tcpm] (no subject)

From: [email-masked]
Date: Wed, 21 Apr 2004 10:59:10 -0500

[Few late comments]

Although I have not read the draft thoroughly, I believe it's probably a good idea to fist define the scope of the problem that this working group should try to solve. TCP has a lot of vulnerabilities -- lot more than what this draft identifies -- and it's better to first define which problems should be solved and which one should not be. (Also, if the problem exists only because of BGP, which I don't think is the case, then maybe routers can use IPSec with a well known permanent shared key with different session keys. This will be more secure, compared to this draft, and faster to deploy.)

Moreover, it will also be useful to specify if the proposed solutions can use cryptography or not. Many people are not comfortable with cryptographic techniques partly because of throughput reasons. But in many cases it might be useful to have a low computation cryptographic methods to solve the problems without hurting the throughput. For example, a TCP sender with Time Stamp option could just encrypt the 32 bit timestamp using AES, and practically solve all the problems in this draft. (I am not saying we should do this). Encrypting a 32 bit number doesn't take a lot of time/computation and the receiver doesn't need to keep states to make this work. And, in principle it's not different from having a challenge response cookie.)

--yogesh

ext Mark Allman wrote:
		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?

	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/>

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

---

From: Florian Weimer <[email-masked]>
Date: Wed, 21 Apr 2004 23:51:11 +0200

[email-masked] writes:

> (Also, if the problem exists only because of BGP, which I don't
> think is the case,

BGP is in the focus because it sounds important (it surely is) and
somewhat mystic.  Of course, IRC is also affected.  But other
TCP-based services have pretty low reconnect costs (initially, this
was also true of BGP, I assume).  In this case, attack costs and its
impact relate more unfavorbly to the attacker.

> then maybe routers can use IPSec with a well known permanent shared
> key with different session keys. This will be more secure, compared
> to this draft, and faster to deploy.)

I don't think IPsec on core routers is faster to deploy.  RFC 2385
should be enough for now, but also has got its issues (higher CPU
consumption for processing packets).  IPsec would share these issues
or would result in even more overhead.

> Moreover, it will also be useful to specify if the proposed solutions
> can use cryptography or not. Many people are not comfortable with
> cryptographic techniques partly because of throughput reasons.

Exactly.  Keep in mind that 200 MHz MIPS CPUs are widely deployed.

> But in many cases it might be useful to have a low computation
> cryptographic methods to solve the problems without hurting the
> throughput. For example, a TCP sender with Time Stamp option could
> just encrypt the 32 bit timestamp using AES, and practically solve
> all the problems in this draft.

What about a new TCP option which contains a few random bytes that are
constant for each connection? This option could be checked very
cheaply, maybe some day even by those ASICs which operate at
wirespeed.

> (I am not saying we should do this). Encrypting a 32 bit
> number doesn't take a lot of time/computation and the receiver doesn't
> need to keep states to make this work. And, in principle it's not
> different from having a challenge response cookie.)

You have to encrypt a full 128 bit block, and I doubt it would be much
cheaper than MD5/RFC 2385.

-- 
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.