[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Choosing between IKEv2 and JFK



  It needs to make a statement about the structure of the blob because
the protocol is designed to have certain properties and those properties
are arrived at by using the blob for certain purposes. A completely opaque
blob would only serve as a covert channel. 

  The blob is not "opaque to every party except itself". The blob itself is
not a participant in the exchange, there's only an initiator and a responder
and the blob is opaque to the initiator not to the responder.

  A security protocol has to protect itself against DoS attacks. If that
entails dictating what goes into the blob then so be it. You can't let
fear of patent trolls interfere in engineering good security into a security
protocol.

  Dan.  

On Wed, 13 Mar 2002 11:00:48 PST you wrote
> 
> Ahh yes, good point...
> 
> In which case why does the spec need to make any statements about the
> structure of the blob? if it is opaque to every party except itself what
> interop requirement can exist?
> 
> Wouldn't it be best to leave that part of the spec blank allowing
> implementations to add whatever measures were most useful to them in their
> particular DoS strategy?
> 
> Another advantage of this approach is that the less clever stuff we mandate
> the less risk there is of a patent troll. Don't start with the 'prior art'
> business, even with prior art it can cost $2 million to fight off a suit.
> The only case in which prior art is useful is if the patent troll makes a
> parallel European application and someone notices in time to dump the prior
> art on them.
> 
> I think that we should consider patent troll attacks at least as seriously
> as DoS attacks.
> 
> 		Phill
> 
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
> 
> 
> > -----Original Message-----
> > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com]
> > Sent: Wednesday, March 13, 2002 12:49 PM
> > To: Hallam-Baker, Phillip
> > Cc: 'EKR'; Dan Harkins; ipsec@lists.tislabs.com
> > Subject: Re: Choosing between IKEv2 and JFK 
> > 
> > 
> > > If the packet goes through a NAT the initiator does not know the IP 
> > > address that the packets it sends will have when they arrive.
> > 
> > but the initiator doesn't compute that hash, the responder does -- and
> > it would use the address as seen at the responder, post-NAT.
> > 
> 
> 
> ------_=_NextPart_000_01C1CAC1.635183F0
> Content-Type: application/octet-stream;
> 	name="Phillip Hallam-Baker (E-mail).vcf"
> Content-Disposition: attachment;
> 	filename="Phillip Hallam-Baker (E-mail).vcf"
> 
> BEGIN:VCARD
> VERSION:2.1
> N:Hallam-Baker;Phillip
> FN:Phillip Hallam-Baker (E-mail)
> ORG:VeriSign
> TITLE:Principal Consultant
> TEL;WORK;VOICE:(781) 245-6996 x227
> EMAIL;PREF;INTERNET:hallam@verisign.com
> REV:20010214T163732Z
> END:VCARD
> 
> ------_=_NextPart_000_01C1CAC1.635183F0--