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

Re: cookie verification



On 10 Dec 99, at 11:00, Kanta Matsuura wrote:

Kanta, 

> Valery,
> 
> Despite the current implementations,
> I wonder if such amount of SA proposals are
> intrinsically necessary.

If initiator doesn't know beforehand responder's capabilities, he 
probably would include in proposals list all the combinations he 
supports and consideres adequate to protect this traffic. Even 
leaving non-standard Oakley groups and different lifetimes it is more 
than three hundred of combinations for Main Mode with current IKE 
definitions and this number will only grow as number of defined 
attributes and their values will grow in future.

Regards,
Valera Smyslov.

> "Valery Smyslov" <svan@trustworks.com> wrote:
> >>On 9 Dec 99, at 10:55, Sami Vaarala wrote:
> >>> Indeed it is: the first message does not require a responder
> >>> to store state.  An approach similar to this one (with
> >>> regards to re-sending the data in the first message later)
> >>> could work for other IKE modes as well, without making the
> >>> exchanges longer.  I wonder if this could be done easily
> >>> using a "standard transform" to a given stateful mode?
> >>
> >>I thought about this also. Resending the data in the first message 
> >>later has its disadvantages when the amount of data is big enough. 
> >>And it is the first IKE packet where this often may be true - unlike 
> >>the other IKE packets, which size is limited (unless you send a lot 
> >>of certs or VendorID payloads), the first packet may contain SA with 
> >>hundreds of proposals. Resending such amound of data only for anti-
> >>clogging purposes seems not to be a reasonable. Perhaps adding one 
> >>more roundtrip of pure cookie exchange would be better. But, 
> >>unfortunately, in any case it requires modification of IKE.
> 
> --^^--
> Kanta
> 




Follow-Ups: References: