IKEv1 Proxy ID

What is a Proxy ID? This is a question that has confused me for quite a long time. Internet searches don't reveal much, and the term never actually appears in any RFCs related to IKE. It wasn't until I stumbled across an old post on comp.dcom.vpn from 2006 that it started to become clear.

History

The term proxy was used quite a bit in the early draft RFCs for Phase 2 Quick mode, but pretty much vanished from use in draft-ietf-ipsec-isakmp-oakley-05. An analysis using the grep command reveals that the word proxy (or some derivation of it) appeared 7 times in drafts 00 to 03, six times in 04, and only once in each draft since.

Appearance of proxy in IKEv1 RFCs

juniper@server:~/IKEv1-rfcs$ grep -i prox *
draft-ietf-ipsec-isakmp-oakley-00.txt:   Proxy negotiation-- in which the negotiating parties are not the
draft-ietf-ipsec-isakmp-oakley-00.txt:   place-- is supported.  When used in proxy mode, identities of the end
draft-ietf-ipsec-isakmp-oakley-00.txt:   and MAY be used in the negotiated SA. If ISAKMP is acting as a proxy
draft-ietf-ipsec-isakmp-oakley-00.txt:   the ISAKMP negotiators are proxies for other parties which have
draft-ietf-ipsec-isakmp-oakley-00.txt:      ~              ID of source for which ISAKMP is a proxy         ~
draft-ietf-ipsec-isakmp-oakley-00.txt:      ~           ID of destination for which ISAKMP is a proxy       ~
draft-ietf-ipsec-isakmp-oakley-00.txt:   destination (in the event that there is no proxy negotiation it will
draft-ietf-ipsec-isakmp-oakley-01.txt:   Proxy negotiation is supported.  Proxy mode is where the negotiating
draft-ietf-ipsec-isakmp-oakley-01.txt:   negotiation is taking place.  When used in proxy mode, the identities
draft-ietf-ipsec-isakmp-oakley-01.txt:   If ISAKMP is acting as a proxy negotiator on behalf of another party
draft-ietf-ipsec-isakmp-oakley-01.txt:   the ISAKMP negotiators are proxies for other parties which have
draft-ietf-ipsec-isakmp-oakley-01.txt:      ~              ID of source for which ISAKMP is a proxy         ~
draft-ietf-ipsec-isakmp-oakley-01.txt:      ~           ID of destination for which ISAKMP is a proxy       ~
draft-ietf-ipsec-isakmp-oakley-01.txt:   proxy for whom the peers are negotiating can be protected with PFS.
draft-ietf-ipsec-isakmp-oakley-02.txt:   Proxy negotiation is supported.  Proxy mode is where the negotiating
draft-ietf-ipsec-isakmp-oakley-02.txt:   negotiation is taking place.  When used in proxy mode, the identities
draft-ietf-ipsec-isakmp-oakley-02.txt:   If ISAKMP is acting as a proxy negotiator on behalf of another party
draft-ietf-ipsec-isakmp-oakley-02.txt:   the ISAKMP negotiators are proxies for other parties which have
draft-ietf-ipsec-isakmp-oakley-02.txt:      ~              ID of source for which ISAKMP is a proxy         ~
draft-ietf-ipsec-isakmp-oakley-02.txt:      ~           ID of destination for which ISAKMP is a proxy       ~
draft-ietf-ipsec-isakmp-oakley-02.txt:   proxy for whom the peers are negotiating can be protected with PFS.
draft-ietf-ipsec-isakmp-oakley-03.txt:   Proxy negotiation is supported.  Proxy mode is where the negotiating
draft-ietf-ipsec-isakmp-oakley-03.txt:   negotiation is taking place.  When used in proxy mode, the identities
draft-ietf-ipsec-isakmp-oakley-03.txt:   If ISAKMP is acting as a proxy negotiator on behalf of another party
draft-ietf-ipsec-isakmp-oakley-03.txt:   the ISAKMP negotiators are proxies for other parties which have
draft-ietf-ipsec-isakmp-oakley-03.txt:      ~              ID of source for which ISAKMP is a proxy         ~
draft-ietf-ipsec-isakmp-oakley-03.txt:      ~           ID of destination for which ISAKMP is a proxy       ~
draft-ietf-ipsec-isakmp-oakley-03.txt:   proxy for whom the peers are negotiating can be protected with PFS.
draft-ietf-ipsec-isakmp-oakley-04.txt:   Proxy negotiation is supported.  Proxy mode is where the negotiating
draft-ietf-ipsec-isakmp-oakley-04.txt:   negotiation is taking place.  When used in proxy mode, the identities
draft-ietf-ipsec-isakmp-oakley-04.txt:   If ISAKMP is acting as a proxy negotiator on behalf of another party
draft-ietf-ipsec-isakmp-oakley-04.txt:   ISAKMP negotiators are proxies for other parties which have requested
draft-ietf-ipsec-isakmp-oakley-04.txt:      ~              ID of source for which ISAKMP is a proxy         ~
draft-ietf-ipsec-isakmp-oakley-04.txt:      ~           ID of destination for which ISAKMP is a proxy       ~
draft-ietf-ipsec-isakmp-oakley-05.txt:   ISAKMP negotiators are proxies for other parties which have requested
draft-ietf-ipsec-isakmp-oakley-06.txt:   ISAKMP negotiators are proxies for other parties which have requested
draft-ietf-ipsec-isakmp-oakley-07.txt:   ISAKMP negotiators are proxies for other parties which have requested
rfc2409.txt:   negotiators are proxies for other parties which have requested
juniper@server:~/IKEv1-rfcs$
   

Essentially the Proxy Identity, or Proxy-ID is an old term that refers to the set of traffic that belongs to an IPSEC VPN and will be subjected to the SA that is being negotiated between peers (or setup once the negotiation has suceeded). The It is used to identify and direct traffic to the appropriate tunnel in cases where multiple tunnels exist between two peers, and to allow for unique and shared SAs with different parameters to coexist.

Reading IKEv1 draft 04, the use of the word Proxy ID to describe the process above makes quite a bit of sense. In the dicussion of Quick Mode in section 5.4, the draft specifies "If ISAKMP is acting as a proxy negotiator on behalf of another party the identities of the parties MUST be passed as IDui and then IDur." It mentions the word proxy, and identity several times but never actually assigns a concrete name to these parameters. The format of the Quick Mode payload has two fields for "ID of source for which ISAKMP is a proxy" and "ID of destination for which ISAKMP is a proxy". These are pretty wordy, so since the word identity is used in several places in the RFC, referring to these particular identities as the Proxy ID makes quite a bit of sense.

Section 5.8.2 from draft-ietf-ipsec-isakmp-oakley-04 Quick Mode

   
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~            ISAKMP Header with XCHG of Quick Mode,             ~
      ~   Next Payload of ISA_HASH and the encryption bit set         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !     ISA_SA    !    RESERVED   !        Payload Length         !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                 keyed hash of message                         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !   ISA_NONCE   !    RESERVED   !         Payload Length        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                 Domain Of Interpretation (DOI)                !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                          Situation                            !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !       0       !    RESERVED   !        Payload Length         !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !  Proposal #1  ! PROTO_IPSEC_AH!  SPI size   |  # Transforms   !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                        SPI (8 octets)                         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !    ISA_TRANS  !    RESERVED   !        Payload Length         !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !  Transform #1 !     AH_SHA    |          RESERVED2            !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                       other SA attributes                     !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !       0       !    RESERVED   !        Payload Length         !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !  Transform #1 !     AH_MD5    |          RESERVED2            !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                       other SA attributes                     !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !    ISA_ID     !    RESERVED   !        Payload Length         !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                            nonce                              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !    ISA_ID     !    RESERVED   !        Payload Length         !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !      0        !    RESERVED   !        Payload Length         !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~           ID of destination for which ISAKMP is a proxy       ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      

In the proposed standard RFC2409, these two fields in quick mode are now called "ID of source for which ISAKMP is a client" and "ID of source for which ISAKMP is a destination." All of the language describing acting as a proxy has been replaced with the word client negoiator on behalf of others, except for the description of the payload for Quick Mode in section 7.2.

Why are Proxy-IDs important?

Ideally, proxy IDs are supposed to identify what traffic belongs to a particular IPSEC VPN. This lets an operating system install the appropriate hooks to direct traffic that matches the source and destination address in the proxy ID (client ID) and direct it into the matching IPSEC SA/VPN. into and out of the matching IPSEC SAs.

The behaviour of what a proxy ID does really seems to be implementation dependent. Some implementations seem to ignore them completely, some live by them, some will only complete Quick Mode if everything matches, other's can be configured to behave in every way possible. For the most part, and especially with the SRXs (at this moment in time), if the Proxy IDs don't match between the peers negotiating an SA in Quick Mode the IKE exchange will fail.

Who Still Uses Proxy-ID Nomenclature

The term Proxy-ID seems mainly to be used by Juniper, inheriting it from buying Netscreen. But it does appear with other vendors as well.

I know of or have found the following vendors referring to a Proxy Identity of some sort:

• Juniper
Netscreen, which was later bought by Juniper uses the term Proxy ID.
• Palo Alto
Founded by some of the original Netscreen-ers so what do you expect.
• Cisco
Uses the term proxy identity in a few error messages and troubleshooting procedures.

Setting the Proxy ID

Here is a quick cheat sheet on how to set the "proxy-id" on various IPSEC implementations.

• Juniper SRX
Normally the Proxy IDs are set to 0.0.0.0/0 for both the remote and local identity for route based VPNs, and are set as the IP addresses and subnets in the "match" parameters of policy based VPNs. These can be overriden with the command: set security ipsec vpn <VPN NAME> ike proxy-identity <local | remote > <IP address/prefix in CIDR format>
• Netscreen
set vpn <VPN NAME> proxy-id local-ip <IP address/prefix in CIDR format> remote-ip <IP address/prefix in CIDR format> any
• strongSwan
The proxy IDs are set with the leftsubnet=<IP address/prefix in CIDR format> for the local Proxy ID, and rightsubnet=<IP address/prefix in CIDR format> for the remote Proxy ID.
• Cisco IOS
The Proxy IDs are set from the access lists that are applied to the crypto maps.