Re: IKE negotiation/rekeying problem with RSIP

"Michael C. Richardson" <mcr@sandelman.ottawa.on.ca> Wed, 17 November 1999 04:21 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17618; Tue, 16 Nov 1999 20:21:19 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA27204 Tue, 16 Nov 1999 22:10:23 -0500 (EST)
Message-Id: <199911170313.WAA05060@istari.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: Re: IKE negotiation/rekeying problem with RSIP
In-Reply-To: Your message of "Wed, 17 Nov 1999 03:28:11 +0200." <199911170128.DAA08180@torni.ssh.fi>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset="US-ASCII"
Date: Tue, 16 Nov 1999 22:13:27 -0500
From: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Tero" == Tero Kivinen <kivinen@ssh.fi> writes:
    Tero> What? I think almost all the implementations are doing exactly that.
    Tero> At least we are doing it... I might of course be wrong in this case...

ike source port (was: issues with IKE that need resolution)
http://www.sandelman.ottawa.on.ca/ipsec/1998/09/msg00102.html

from:
http://www.sandelman.ottawa.on.ca/ipsec/1998/09/msg00064.html
     * Subject: issues with IKE that need resolution
     * From: Daniel Harkins <dharkins@cisco.com>
     * Date: Fri, 11 Sep 1998 10:48:12 -0700

I thought there was a followup that lead to the first part.

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.

  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.

   :!mcr!:            |  Cow#1: Are you worried about getting Mad Cow Disease?
   Michael Richardson |  Cow#2: No. I'm a duck.
 Home: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface
Charset: noconv

iQDVAwUBODIdVXMJp3VWzPepAQFyCwYAo96CvWYai+x+P/WophlwwMkCpsJAdcx3
wUW3hfsntjBWjxjn2vJE73XwCP8Z/S4B7/L7tgzfhd+MILm9uxY5+shpaneVMWJD
NIy02FKd0ylMM/WG6k3F2tlfNbPQ/ZdvU5OpOwCgp3KRowRZd8KmPS6boilVkrFo
Tw7F9q3CBAPIpYn4lN6eniYiRdVdNtEHhjm6lyaYvYdtZB/RkGK7W56ozDfFwevQ
ifuOG+tyGTeTO2FzOL0/4l3/DSFDdxtv
=csFY
-----END PGP SIGNATURE-----