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

Re: ike source port (was: issues with IKE that need resolution)

> >        Is it ok for the source port for IKE to be something other than
> >        port 500?
> 
...

> 
> My biggest concern is that making a "fix" to allow any source port to
> initiate ISAKMP traffic - make that a change to mandate that ISAKMP
> responders respond to ports other than 500, which isn't a requirement
> currently - is going to give people the false impression that doing
> so magically fixes the "IPSEC/NAT problem" across the board, when in
> fact it only addresses part of the problem for only a subset of the
> possible scenarios where IPSEC can be used - the subset where there is
> a strict client-to-server, initiator-to-responder assignment of roles
> that doesn't ever change.  I don't want to have to try to explain to
> someone why the NAT box they just installed breaks IPSEC communications
> in some cases but not in others.


That's a valid concern, but, as with all hooks in general, they
are not claimed to be a fix. They're only what makes a fix possible.
If deemed necessary the appropriate provisos could accompany any
changed text. Besides, relaxing the port constraint is beneficial
for other things as well, such as testing (see below).

What's MUCH more important is figuring out what security issues
arise (if any) by allowing source port
(and destination port, for that matter) to be different from 500.

Given that the hash covers it, perhaps it is already taken care
of. 

> 
> >[...] Allowing the source port to vary does not
> >seem to have security implications, because source and destination
> >ports are already included in the hash. [...]
> 
> Actually, source and destination ports (those in the UDP header at
> least) aren't included in any of the IKE hash calculations.

according to section 5 of IKE:

	The entire ID payload (including ID type,
   	port, and protocol but excluding the generic header) is hashed into
   	both HASH_I and HASH_R.

However, I looked at the DOI, and it does impose severe constraints
on the port number used:

   During Phase I negotiations, the ID port and protocol fields MUST be
   set to zero or to UDP port 500.  If an implementation receives any
   other values, this MUST be treated as an error and the security
   association setup MUST be aborted.  This event SHOULD be auditable.


By the way, allowing port numbers to be something other than 500
also helps testing. The SSH Communications test facility uses
ports other than 500:

	http://isakmp-test.ssh.fi/cgi-bin/nph-isakmp-test

Of course, that practice is wrong, according to the DOI paragraph
above. 

Maybe the DOI (and IKE) should not limit it to source port 500
(and destination as well, for that matter)?

-gabriel
References: