On Mon, 8 Aug 2016, Tero Kivinen wrote:
Paul Wouters writes:
As explains in another thread on the list, that just complicates sending
this information down to a locally running DNS server. None of the
current ones take DNS wireformat for on-the-fly reconfiguration.
However, they do take DNS presentation format. Also, for instance if
you look at the libreswan implementation, this data is passed into
the connection handler via environment variables, so libreswan would
have to convert the DNS wire format to DNS presentation format before
giving it to the handler for DNS reconfiguration.
We are specifying the IKEv2 protocol extension, not really specifying
how to pass the information forward. If some implementation is using
environment variables, or command line options to pass this
information forward I think some kind of binary format is better in
IKEv2 than string format.
Well, we have been passing domain names to forward via IKEv1 XAUTH for
10+ years and I've never heard of a problem with passing domain names
as strings. I find this "security software authors might do dangerous
string passing" a rather unconvincing argument.
Ifwe use string format the IKEv2 implementations might easily just
pass the string forward without any checking, and this might cause
security vulnerabilities like we had with shellshock or similar.
We are talking about dedicated security software here, not /bin/bash. If
your security software can't do string passing, you already are using
a timb bomb.
If the input format is some kind of binary format, and the IKEv2
library then constructs the string format out of that it will remove
ability to do that kind of attacks.
Why? You don't think attackers can encode weird characters in binary
which would be "blindly" decoded into ascii with the same dangerous
characters inside?
With string formats we need to make sure that there is nothing
dangerous in there ("$INCLUDE /etc/passwd" or "; `sh -c
/sbin/reboot`") and we have to specify what kind of checking
implementations should do on the format.
Same for binary format? We either have to write our own routines (more
likely) or link against a DNS library that has this functionality.
Like using ldns, which would drag in so much code people more likely
will copy the wire conversation functions from some dns library into
their code and never update that code again, possibly leaving in
security vulnerabilities.
Saying that the contents is DS RDATA wire format as specified in the
RFC4034 section 5.1 would be much easier, and converting that to
string representation is quite easy, as it is just 1 16-bit field, two
8-bit field, and then the digest:
And now you have to understand DNS wire format and all their possible
changes, use of compression, sneaking in multiple records, etc etc.
INTERNAL_DNS_DOMAIN(example.com,31406,8,2,
0xF78CF3344F72137235098ECBBD08947C2C9001C7F6A085A17F518B5D8F6B916D)
I understand you can do this, but it does add a string2wire() and
wire2string() operation for what I believe is a red-herring for security
reasons.
I do not understand why the TTL is ignored. I also think that
would be important in case of KSK roll-over.
The TTL is ignored because this is an administrative reconfiguration.
Just like a DNS server loading trust anchors from a file, there is no
TTL to that file-based information either.
If the zone does a KSK roll without updating the IPsec server, it is
an administrative error. Possibly, the IPsec server could have code
that reads the KSK's hourly and auto-updates what it gives to its
clients, but that would all be implementation specific and I don't
think this document needs to specify that.
It is not enough for the IPsec server to fetch KSK, as the client
might have fetched the TA information two months ago, when it
connected to the SGW. It might have done several IKEv2 rekeys after
that, but as it does configuration payloads only when it initially
connects it will not get new configuration information ever.
Perhaps that needs clarification, but my idea was that you purge the
trust anchor and the zone data underneath it when you tear down the
IPsec SA. The VPN tunnel is not meant to be a replacement for RFC-5011
style trust anchor updating. The split-DNS view can be changed at any
time by the server/internal network and clients MUST NOT store this
information as a permanent update. I will add language to clarify that.
This might not be something that we actually need to fix here, it
might be enough just to add some words about that, and say that if
internal domain does KSK roll overs then the server might want to
request clients to do reauthentication (RFC4478) while doing roll over
so they will get new configuration information before the old one is
removed.
Any internal KSK roll should be done slowly enough (days or weeks) so
that any VPN client connecting can always pull a working DNSKEY RRset.
Perhaps a re-key or re-auth event should allow to request/send a new
CFG set to keep updated for very long lived tunnels?
Well, the idea here is that you will not be able to resolve that
resource unless you accept DNS server for it. If you say SHOULD instead
of MUST, it means you are going to fail to resolve the internal
resource. As for using the internal DNS for more than advertised, if the
internal DNS server is okay with resolving everything, it could send
the value ".". We could clarify that explicitly.
Internal server might be willing to resolve everything, and even
provide completely new DS for "." so you can do everything securely,
but the user might be bit suprised to learn that his facebook.com
requests go to the company dns server, and dnssec is happy with the
faked results pointing to the companys internal facebook proxy that
checks they do not post anything nasty about company to the
facebook...
I am not sure if you are agreeing with the SHOULD or the MUST here? You
seem to be arguing to leave it as MUST?
So this is also security issue, i.e., how much configuration you
should trust from the server. Bad server can send you bad
configuration data, and client might want to limit the damage done by
the bad server.
Which is why the client can send the list of domains it is willing to
have overridden, or it can interpret the received list. And it can
ignore "." if that is not in its locally accepted list.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
