[tcpm] (no subject)

[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
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm