[nsp] Identification Payload violates RFC 2407, section 4.6.2 ???

[Michael D. Schleif]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We are trying to build an ipsec tunnel between a freeswan v1.91 based
router and a Cisco 3662 Router with IOS 12.2(12) with Hardware
encryption accelerator.

Problems occur during Identification Payload at the freeswan device:

Jun  5 17:01:56 pinktrout Pluto[32385]: "go-net" #19: initiating Main \
  Mode
Jun  5 17:01:56 pinktrout Pluto[32385]: "go-net" #19: ignoring Vendor \
  ID payload
Jun  5 17:01:56 pinktrout last message repeated 3 times
Jun  5 17:01:56 pinktrout Pluto[32385]: "go-net" #19: protocol/port in \
  Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0
Jun  5 17:02:24 pinktrout Pluto[32385]: packet from 204.235.103.2:500: \
  Informational Exchange is for an unknown (expired?) SA
Jun  5 17:03:06 pinktrout Pluto[32385]: "go-net" #19: max number of \
  retransmissions (2) reached STATE_MAIN_I3.  Possible authentication \
  failure: no acceptable response to our first encrypted message
Jun  5 17:03:06 pinktrout Pluto[32385]: "go-net" #19: starting keying \
  attempt 17 of an unlimited number


Here is RFC 2407, section 4.6.2:

4.6.2 Identification Payload Content

   The Identification Payload is used to identify the initiator of the
   Security Association.  The identity of the initiator SHOULD be used
   by the responder to determine the correct host system security policy
   requirement for the association.  For example, a host might choose to
   require authentication and integrity without confidentiality (AH)
   from a certain set of IP addresses and full authentication with
   confidentiality (ESP) from another range of IP addresses.  The
   Identification Payload provides information that can be used by the
   responder to make this decision.

   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.


I have searched and searched.  There is *NO* way around this with
FreeS/WAN -- nor ought there to be, since this is a clear and
unequivocal violation of a long standing (November 1998) RFC.

The only viable solution, as one poster to the freeswan mailing list put
it, is:

``The solution is to adjust the configuration of the Cisco box so that
it follows the standard (RFC 2407, section 4.6.2).  The Cisco
documentation should cover how to do this and/or it might be a FAQ in
a Cisco mailing list or newsgroup.''


We have successfully established ipsec vpn's between other cisco devices
and other freeswan devices.

What is the best workaround here?

What do you think?

- -- 
Best Regards,

mds
mds resource
877.596.8237
- -
Dare to fix things before they break . . .
- -
Our capacity for understanding is inversely proportional to how much
we think we know.  The more I know, the more I know I don't know . . .
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+6TT/LUOEaCtUQpwRAu8vAKCBMzWmbKC5YGKZ/RvsfxVaThI8AwCfeUV9
S+tdfOSolnaAvIcf6nqKYjY=
=ARol
-----END PGP SIGNATURE-----