Re: protocol/port in Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0 (seems to be an old problem ???)

Okay... I was being lazy. It seems that the relevant rfc is 2407, and
I'm looking at it at: http://www.faqs.org/rfcs/rfc2407.html

The section I can see that is relevant is 4.6.2, and some extracts that
are specifically relevant are:

"  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."

"    o  Protocol ID (1 octet) - Value specifying an associated IP
        protocol ID (e.g. UDP/TCP).  A value of zero means that the
        Protocol ID field should be ignored.

     o  Port (2 octets) - Value specifying an associated port.  A value
        of zero means that the Port field should be ignored."

I feel that the the first paragraph I quoted is a little ambiguous, is
it saying that:
(protocol must be 0 and port must be 0) or (protocol must be 17 and port
must be 500) (this is ipsec_doi.c 's interpretation).
Or is it saying that
(protocol must be 17 or 0) and (port must be 500 or 0) (cisco conforms
to this interpretation)

I think the second bit I quoted clarifies it in cisco's favour though,
where the interpretation would be that 17/0 means that the protocol is
udp and to ignore the port.

The above summary is based on a pretty quick browse of the rfc, so I may
have missed something. I'll have a more thorough read later when I have
time, unless someone else gets there first.

ipsec_doi.c has the following comment in it:

    /* I think that RFC2407 (IPSEC DOI) 4.6.2 is confused.
     * It talks about the protocol ID and Port fields of the ID
     * Payload, but they don't exist as such in Phase 1.
     * We use more appropriate names.
     * isaid_doi_specific_a is in place of Protocol ID.
     * isaid_doi_specific_b is in place of Port.
     * Besides, there is no good reason for allowing these to be
     * other than 0 in Phase 1.
     */

which just confuses me :)

james


> -----Original Message-----
> From: D. Hugh Redelmeier [mailto:[email protected]]
> Sent: Monday, 3 November 2003 02:20
> To: Sam Sgro
> Cc: FreeS/WAN Users; FreeS/WAN Design; James Harper; Thomas
> Subject: Re: [Users] protocol/port in Phase 1 ID Payload must be 0/0
or
> 17/500 but are 17/0 (seems to be an old problem ???)
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
>=20
>=20
> | From: Sam Sgro <[email protected]>
>=20
> | D. Hugh Redelmeier's explanation:
> |
> | http://lists.freeswan.org/pipermail/design/2002-January/001810.html
>=20
> An even more clear response:
>
<http://lists.freeswan.org/pipermail/users/2003-January/017808.html>
>=20
> On the surface, this appears to be a bug in Cisco's IKE
> implementation.  It has shown up on our lists at least since January.
> Has anyone reported it to Cisco?
>=20
> If not: why not?  I'm not a Cisco customer or even user so I'm not the
> best guy to report it.  I'm loath to add a bug to FreeS/WAN (yes, bug:
> read Stephen's message) to compensate for a bug in Cisco's code.
>=20
> If so: what has their response been?  Is there a configuration fix for
> the Cisco end?  Is there a software update fo fix it?  Have they
> claimed that this is not a bug?
>=20
> Hugh Redelmeier
> [email protected]  voice: +1 416 482-8253
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: noconv
>=20
> iQCVAwUBP6UguMFAuQPManGZAQEeNAP/XlNch/gZ85c/aoJxnSZEG3G+UL+70GvV
> cdt9WW4SvIFFbPxaRUHmXRtvq5cmPKFbB8DAQSVNvkaJ9DRr5pDAiXd1zOxsCnBL
> He34gV9GigGQousMd8ONQMR7uHUY7QA/2Ijpx7tzb+aGlztNxe4wuvtkUHgIl3zf
> ikxR+mNfm1k=3D
> =3DgFmo
> -----END PGP SIGNATURE-----