[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE negotiation/rekeying problem with RSIP
"Michael C. Richardson" <mcr@sandelman.ottawa.on.ca> wrote:
(some stuff elided...)
>Aha...
> http://www.sandelman.ottawa.on.ca/ipsec/1998/09/msg00124.html
>
>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.
yes, the above text is from a message i sent to the list.
> Well, I can see why I beleived that the source port had to 500.
> An implementation which replies to any port would work seemlessly
>with implementations that sent from port 500, and if you have port 500
>open to receive, it seems simple enough to receive on that port as well.
are you saying my msg had the opposite effect from what was intended?
hmmm... good thing i'm not a peace negotiator...
anyway, after all the exchange between tero and mcr it can be concluded that
(notice it starts with 'if'):
If an implementation allows other-than-port-500 for IKE,
it no longer sets the value of the port numbers as reported in the
ID payload to 500, but 0 (meaning "any port"). UDP port numbers
(500 or not) are handled by the common "swap src/dst port and reply"
method.
should some wording to clarify this (perhaps along the lines above)
go into the currently-being-updated ike document?
-gabriel