Re: [design] protocol/port in Phase 1 ID Payload must be

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


| From: James Harper <[email protected]>

| 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

Good. 

| 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)

No, the first is not ambiguous.  It says that:
 During Phase I negotiations [i.e. not Phase II],
 the ID port and protocol fields [a pair]
 MUST [both] be set to zero [i.e. the pair 0,0]
 or to UDP port 500 [i.e. the pair 17, 500].

The second quoted part restricts both Phase I and Phase II ID
Payloads.  The extra lattitude is for Phase II.

So: both restrictions apply to Phase I.  The alleged behaviour of
Cisco's code violates the RFC.

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

That would be true if the ID payload were for Phase II.

| 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 :)

This quote doesn't really address the issue.  The direct quote of
4.6.2 is more relevant.

What I meant by the comment:
The Phase I ID payload layout should be defined in a DOI-independent way.
Protocol and Port are IPsec-specific rather than being generic to IKE.
Furthermore, There is no information being conveyed in these fields in
Phase I.

Hugh Redelmeier
[email protected]  voice: +1 416 482-8253

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBP6WvAsFAuQPManGZAQGAqAQAiPqvD2UgtHJj+nluRVqojf2mgWNfbt2v
xvDCQbiMOu3u6BXn4sM9nKtaDPzNPf5cuoQdyoNMqwq3dlM6yxIzmWCcLd6k/JRx
JYEfaICxKScluj3HaGLI11eI1nX3nAm47bZRrdeHK6RGw3K5ckwzJF2tYq3Moi4j
Ig4DHUbv3H4=
=11hO
-----END PGP SIGNATURE-----