Project

General

Profile

Feature #3162

Strongswan Android support for default DNS suffixes (UNITY_DEF_DOMAIN flag)

Added by Brandon Chalk over 1 year ago. Updated over 1 year ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
android
Target version:
-
Start date:
29.08.2019
Due date:
Estimated time:
Resolution:

Description

Since it's already in the protocol common with many implementations, I was hoping to see the support to honor the default DNS domain suffix flag UNITY_DEF_DOMAIN sent from the server.

I went ahead and through together a sloppy proof of concept that seems to work, but it is minimally tested, it contains no unit tests, and it was not written by someone familiar with the project, but it may serve a reference if someone wants to implement and add this to the client.

Thanks!

PoC:
https://github.com/brandoncasaba/strongswan/commit/958e5816d778756874aca51b2b506500e83cde93

History

#1 Updated by Tobias Brunner over 1 year ago

  • Category set to android
  • Status changed from New to Feedback

Since it's already in the protocol common with many implementations

What implementations are you referring to? Are you saying there are IKEv2 implementations that exchange that attribute? Or are your referring to IKEv1 implementations?

I was hoping to see the support to honor the default DNS domain suffix flag UNITY_DEF_DOMAIN sent from the server.

Please note that this configuration attribute is from a proprietary IKEv1 extension, defined in the reserved private use range (28674, which technically can only be interpreted that way if the Cisco Unity vendor ID was exchanged). There is no standardized attribute for this functionality for IKEv2, which the Android app uses (RFC 8598 added the equivalent of UNITY_SPLITDNS_NAME but no attribute to configure a default DNS suffix).

That strongSwan can be forced to send such attributes also for IKEv2 is just due to the flexibility (or perhaps limitation) of the attr, vici and other configuration attribute backends. It's technically not compliant with the protocol.

So I'm a bit torn on adding support for this attribute (I also think people who rely on default DNS suffixes are lazy and open themselves up for numerous problems as it makes domain names ambiguous).

Also available in: Atom PDF