[Ipsec-tools-commits] [ ipsec-tools-Feature Requests-1006090 ] use of FQDNs instead of IP-addresses

[SourceForge.net <no...@so...>]

Feature Requests item #1006090, was opened at 2004-08-09 19:13
Message generated for change (Comment added) made by monas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=541485&aid=1006090&group_id=74601

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: use of FQDNs instead of IP-addresses

Initial Comment:
i've got 2 hosts on the internet with changing
IP-addresses at least every 24hours. each hosts
reconnects immediatelly and updates its DNS-entry (at
dyndns.org). using hostnames instead of IP-addr with
setkey works, but it immediatelly resolves them and
then these IP-addresses (in the policies) are never
updated again, thus the IPsec (transport) -connection
between the two is gone. ok, i could put a one-liner in
the ppp-up-script calling setkey, but if the two hosts
don't redial about the same time, i always have to
check if the peer's DNS-entry has changed and then call
setkey again. so using FQDNs would be much nicer; this
was possible with FreeS/WAN, IIRC. so, the DNS was
always asked when phase 1 started -- of course this is
somewhat lavish, but otherwise i'd have to check
automanually (cron) (much more lavish in case of a
seldomly used IPsec-connection).
is this possible with recent ipsec-tools and linux 2.6?
are there any plans to implement this feature? TIA


/Holger Duell

----------------------------------------------------------------------

>Comment By: Aidas Kasparas (monas)
Date: 2004-08-10 07:53

Message:
Logged In: YES 
user_id=39627

Hi, Holger,

I agree -- it would be good to have feature you're
requesting. Unfortunatelly, with 2.6's ipsec architecture it
is close to imposible to implement it (or at least I have no
idea, how to do so). And this is why.

All the "dirty" work (finding out, should packet be subject
of ipsec processing,  en/de-capsulations) is done by kernel.
To make these decissions kernel maintains SPD (Security
Policy Database). All the addresses in that database are
held in IP form. And there is a good reason for that -- this
database is consulted for _EVERY_ packet. So, if we would
put FQDN here, then we would need to send some dns packets
first to find out, if given rule should apply. But these
packet should be subject to SPD rule check => we get
infinite loop. And therefore we CAN  NOT use FQDNs in
selectors => transport mode becomes unuseable.

For tunnel mode there is no such fundamental problem AFAIK.
But to implement it one would need to:
- invent syntax, how to specify, that FQDN addresses should
not be resolved;
- modify kernel, to accept, store and return policies with
tunnel endpoints as strings;
- modify ipsec-tools to know how to deal with such policies.

I'm affraid, advocating changes in kernel woult be not an
easy task.

May I suggest a workaround? You can listen on some port
(using xinetd), and on every (rate-limited) connection to
that port, you could check dns for peer's address changes
and update setup accordingly. Your ip-up then should telnet
to that port after it has registered it's IP in dns. You may
need to setup extra rule in ipsec to allow packets on that
port through.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=541485&aid=1006090&group_id=74601