[strongSwan-dev] IKE_AUTH with IDi and IDr

Peter Hsiang phsiang at nvidia.com
Fri Sep 5 23:33:22 CEST 2014

Hi Martin,

Thanks for the clarification.

The RFC chapter 3.5 says the IDi IDr identity may be used for policy lookup.  In Strongswan, on the server side, what is the IDi IDr used for in the current implementation for, say, IKEv2?  Like, if the FQDN type format is used, does it use the FQDN to lookup an IP address?

What does the "@" wildcard in front of the FQDN do?
In ike_auth.c method build_i, idr->contains_wildcards(idr) becomes true when I have the @.

Only without the @, the IDr is created.

My guess is, the right_id is sent from client to host, regardless of whether or not the IDr is constructed.  Is the right_id sent in packets other than in IDr?


-----Original Message-----
From: Martin Willi [mailto:martin at strongswan.org] 
Sent: Thursday, September 04, 2014 1:20 AM
To: Peter Hsiang
Cc: dev at lists.strongswan.org
Subject: Re: [strongSwan-dev] IKE_AUTH with IDi and IDr


> In the current implementation, what strongswan configuration parameter 
> corresponds to what gets placed into the IDr?

As discussed, the IDr proposed as initiator is solely based on the rightid (or the subject of a rightcert) parameter.

> I suppose it's different from the right_id because the right_id is 
> usually a URL ending with a ".org", while the APN is a plain text 
> string name.

It's not an URL, it is an IKE identity. An IKE identity has a type and associated binary data. The binary data is type specific. The different types of identities known by IKE are defined at RFC 5996 3.5. Most common types are FQDN, E-Mail or ASN1 Distinguished names.

There is no "plain text" type of identity. To encode an APN, you'll have to choose one of the existing types; FQDN is probably just fine. Your spec definitely should say what is to use here.

When configuring rightid in ipsec.conf, strongSwan determines the type of the identity automatically. When configuring an APN, it is probably handled as FQDN.


This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

More information about the Dev mailing list