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

Re: Agenda for the Minneapolis meeting



But my thinking here is, still GDOI is an extension to IKE or for that
matter they are all based on ISAKMP. UDP 500 is ISAKMP port number. My
feeling is all applications that use IKE/ISKAMP must use 500. Otherwise
ISAKMP will have list of UDP sockets for each DOI..

I agree as you said, stateful tracking of SA require bit of work.

At 03:11 PM 3/15/01 -0800, Dan Harkins wrote:
>  They are "similar" but not "identical". Therefore they are different.
>
>  I'm sure the implementations you refer to are very efficient and also
>very secure. It is still a bad idea. The complexity of the daemon
>listening on that port grows and the security of every protocol becomes
>tied to whatever else is being multiplexed. An attack on the FOO exchange 
>in the BAR DOI could be used to create bogus IPsec SAs. 
>
>  Dan.
>
>On Thu, 15 Mar 2001 14:40:32 PST you wrote
>> Dan
>>     It would be one thing to run, say, nfs and ftp on the same port.
>> I would call that "running two different protocols on the same port."
>> That being one case, what do you call it when DOIs which use
>> similar payloads, similar exchanges, and the same header with
>> a switch to identify them are run on the same port?  It is misleading
>> to suggest that the first case is the same as the second.
>> 
>> At 02:04 PM 3/15/2001 -0800, Dan Harkins wrote:
>> >   That just isn't true. KINK defines new payloads and is, itself, a
>> >new exchange. The group DOI is for multicast security and since IKE
>> >establishes a shared symmetric key between two parties and two parties
>> >only a new multicast key exchange has to be defined. Neither of these
>> 
>> GDOI uses that pair-wise symmetric key.
>> 
>> >things should speak out of UDP port 500.
>> 
>> I don't know yet if sharing the same port among different DOIs
>> is an important issue but it's clear that the protocol is designed to
>> demultiplex exchanges that belong to different DOIs.  I know of
>> two implementations where this was implemented very efficiently.
>> 
>> Mark
>> 
>> 
>> >   Dan.
>> 
>