Subject: RE: [tcpm] draft-bonica-tcp-auth-00

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Mon, 7 Nov 2005 14:35:36 -0800

I see that this is going to be presented in TCPM on Thursday. I have few
comments based on our experiences so far in the key rollover stuff.

- Firstly it is really not needed to extend TCP for supporting
key-rollover. We have some implicit methods to do it today.

- Also it is probably not neeeded have an explicit key-identifier
(authentication element)in each and every TCP segment being sent out.

- The draft also talks about providing the ability to switch to multiple
algorithms during the life of a single connection. This appears to be a
overkill. The reason I am saying this because we have MD5 today which is
being deployed "on and off" depending on the on the security
requirements of the customers. Now since MD5 is probably prone to
collision attacks after "some volume" of data transfer, it is probably
desirable to have periodic key changes which is where the topic of
key-rollover commences from. So all I am wondering is in cases where MD5
is used to protect the sessions, doesn't periodic key-rollover help?
Where is the need for changing algorithm type coming from? 

- Like the draft acknowledges, there is a problem that it oversubscribes
the TCP option space. While this may seem ok, in reality it probably
isn't. We have seen several customer configurations employing
timestamps, selective-acks and MD5. 

Just wanted to point out that we did think about a new TCP option a year
back when we first had customers asking us for key-rollover and we
dropped it because of the issues above. The implicit methods without
changing TCP protocol seems to do the desired job necessary to
accomplish rollover. 

$0.02,
-Anantha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ted Faber
> Sent: Monday, September 19, 2005 10:40 AM
> To: Ron Bonica
> Cc: [email-masked]
> Subject: Re: [tcpm] draft-bonica-tcp-auth-00
> 
> On Sat, Sep 17, 2005 at 10:27:46AM -0400, Ron Bonica wrote:
> > Please consider the following draft as an individual submission:
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> [snip]
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-00.txt
> 
> I skimmed this over, and (with my co-chair hat off) the only 
> real concerns I have with this are:
> 
> 	* It seems like a bit of a band-aid on the MD5 TCP stuff,
> 	  without fixing the real problem that it requires configuration
> 	  coordination.
> 	* I think that as specified you're free from problems cause dby
> 	  any but the most ridiculous clock skew, but adding a paragraph
> 	  indicating that's the case probably wouldn't hurt.
> 	  Specifically you might want to address when an endpoint can
> 	  discard authentication entities. You might also want to
> 	  briefly explain that a host receiving a packet authenticated
> 	  with an authentication element that the receiving endpoint
> 	  does not believe has passed its start time is not an error
> 	  because clocks may have skewed.
> 
> Do others have deeper objections?
> 
> --
> Ted Faber
> http://www.isi.edu/~faber           PGP: 
> http://www.isi.edu/~faber/pubkeys.asc
> Unexpected attachment on this mail? See 
> http://www.isi.edu/~faber/FAQ.html#SIG
> 

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