[not waring any hats]
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.
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.
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.
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.
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:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Algorithm | Digest Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Digest /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There would not be need for the TTL, so that is not an issue, but on
the other hand, we need the domain name, so perhaps the
INTERNAL_DNS_DOMAIN would need to be as follows:
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | |
+-+-+-+-+-+-+-+-+ |
~ Domain Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Algorithm | Digest Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Digest ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the Name length tells the lengt of the domain name, and after
that there is optional DS record information for that domain. Whether
the Key Tag / Algorith / Digest Type is there after the Domain name is
seen from the Length field and the Key Tag is followed immediately
after Domain Name without any padding, and without the trailing dot,
and the Domain Name is not null-terminated.
If there is multiple DS records, then there would be multiple
INTERNAL_DNS_DOMAIN records, with same or different domain name.
I.e., in that case the example would be :
CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
INTERNAL_IP4_DNS()
INTERNAL_DNS_DOMAIN(example.com)
INTERNAL_DNS_DOMAIN(other.com)
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_DNS(198.51.100.2)
INTERNAL_IP4_DNS(198.51.100.4)
INTERNAL_DNS_DOMAIN(example.com,31406,8,2,
0xF78CF3344F72137235098ECBBD08947C2C9001C7F6A085A17F518B5D8F6B916D)
INTERNAL_DNS_DOMAIN(example.com,31589,8,1,
0x3490A6806D47F17A34C29E2CE80E8A999FFBE4BE)
INTERNAL_DNS_DOMAIN(example.com,43547,8,1,
0xB6225AB2CC613E0DCA7962BDC2342EA4F1B56083)
INTERNAL_DNS_DOMAIN(example.com,31406,8,1,
0x189968811E6EBA862DD6C209F75623D8D9ED9142)
INTERNAL_DNS_DOMAIN(example.com,31589,8,2,
0xCDE0D742D6998AA554A92D890F8184C698CFAC8A26FA59875A990C03E576343C)
INTERNAL_DNS_DOMAIN(example.com,43547,8,2,
0x615A64233543F66F44D68933625B17497C89A70E858ED76A2145997EDF96A918)
INTERNAL_DNS_DOMAIN(city.other.com)
with DS records given for example.com, but without DS records for
city.other.com.
> > > 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.
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.
> 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...
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.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
