RE: [tcpm] (no subject)

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

I don't know much about router architectures, so I can't really comment whether IPSec or changing TCP is a better solution. But if I were to choose between a well defined protocol and a protocol that is still under discussion in the IETF, I would choose the former.

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

Will work too, but remember that DOFF only allows 15, 32 bit words for TCP options. With SACK, timestamps etc, there is not a lot of room left for new options. Of course this is not too big of a problem.

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

Yes it will be much cheaper. With MD5/RFC 2385, you compute the hash on the entire ~1400 byte packet. With AES or a different stream cipher, it could be a lot less computation.

--Yogesh

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm