Re: [tcpm] (no subject)

[Anantha Ramaiah <[e-mail]>]

Having alternative crypto methods for securing a TCP connection has been 
discussed before. 

Also RFC 2385 suggests the provision of having an algorithm type field 
to be negotiated instead of MD5 and states the reason why that was not
pursued at that time..

-Anantha
[e-mail] wrote:
> 
> > > 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tcpm

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