Hi,
Please find my review for draft-pauly-ipsecme-split-dns-01. The comments
and reviews provided does not prevent the draft to be accepted as WG
document. I think the document should be accepted as WG document.
BR,
Daniel
Split-DNS Configuration for IKEv2
draft-pauly-ipsecme-split-dns-01
Abstract
This document defines two Configuration Payload Attribute Types for
the IKEv2 protocol that define sets of private DNS domains which
should be resolved by DNS servers reachable through an IPsec
connection, while leaving all other DNS resolution unchanged.
> MGLT: "define" is repeated and the sentence is quite long....
1. Introduction
The Internet Key Exchange protocol version 2 [RFC7296] negotiates
configuration parameters using Configuration Payload Attribute Types.
This document defines two Configuration Payload Attribute Types that
add support for trusted split-DNS domains. The INTERNAL_DNS_DOMAIN
attribute type is used to convey one or more DNS domains that should
be resolved only using the provided DNS nameserver IP addresses,
causing these requests to use the IPSec connection. The
INTERNAL_DNSSEC_TA attribute type is used to convey DNSSEC trust
anchors for those domains. When only a subset of traffic is routed
into a private network using an IPSec SA, this Configuration Payload
option can be used to define which private domains should be resolved
through the IPSec connection without affecting the client's global
DNS resolution. For the purposes of this document, DNS servers
accessible through an IPsec connection will be referred to as
"internal DNS servers", and other DNS servers will be referred to as
"external DNS servers".
> MGLT: Maybe that would be helpful to clarify if the DNS server is a
resolution or
> authoritative DNS server. Maybe "internal DNS resolver" would
> be more appropriated.
> I think that the paragraph "When...." defines the problem statement
> and the first "The Internet..." defines the solution. It might
> be clearer to invert the two paragraphs.
> I think the motivation should be better exposed. The reason
> you need the options are:
> - 1) When you have multiple interface to be able to define
> for which domain name the DNS query MUST be sent to internal
resolver.
> - 2) When DNSSEC resolution is activated, you need the TA to
> validate internal resolutions.
> Note, that the architecture implies that my resolution goes through
> the internal resolver. In other words, the mobile cannot have a
> resolver that directly queries the authoritative servers. Maybe that
> would be good the NS are also provided by a INTERNAL_NS_DOMAIN
3. Protocol Exchange
> MGLT: I think the section is missing text that provides an
> overview of the protocol.
> The purpose of the information exchanged between the VPN
> client and the gateway are expected to provide the necessary
> information so the VPN client be informed properly of the
> domains that resolve differently internally than externally.
> In addition, some extra material should be provided so the
> resolution can appropriately be performed.
>
> The purpose of the INTERNAL_DNS_DOMAIN attribute is to
> inform the client of domains whose internal resolution
> defers from the external resolution. When the
> INTERNAL_DNS_DOMAIN the client is expected to receive all
> domains whose private resolution differs for external
> resolution. In addition, the client can also restrict the
> request for a list of FQDN, in which case an optional domain
> is associated to INTERNAL_DNS_DOMAIN. In this case, the
> response will mostly indicate whether the specified domain
> has a private resolution that differs from the external
> resolution. In case the client wants to submit a list,
> multiple INTERNAL_DNS_DOMAIN attributes will be
> provided in the request.
> In order to enable the client to perform the proivate
> resolution, the private network should provide some
> entry points the queries should be sent to. This could
> include internal resolver INTERNAL_IP*_DNS or the
> authoritative servers IP addresses INTERNAL_IP*_NS.
> In addition, when DNSSEC is used, information of the
> private trust anchor should be provided INTERNAL_DNSSEC_TA.
3.1. Configuration Request
To indicate support for split-DNS, an initiator sending a CFG_REQUEST
payload MAY include one or more INTERNAL_DNS_DOMAIN attributes as
defined in Section 4.
If an INTERNAL_DNS_DOMAIN attribute is
included in the CFG_REQUEST, the initiator SHOULD also include one or
both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in its
CFG_REQUEST.
> MGLT: My understanding is that INTERNAL_IP4_DNS and INTERNAL_IP6_DNS
> only concerns the resolution. As resolution could be performed through
> the resolvers as well as by the client I would treat this aspect and
> the recommendations a separate section. The resolution could be for
> example performed by a resolver on the client in which case NS
> records may be requested by the client.
3.2. Configuration Reply
> MGLT: this is a recommendation I would dissociate
> it from the normative description.
If an
INTERNAL_DNS_DOMAIN attribute is included in the CFG_REPLY, the
responder SHOULD also include one or both of the INTERNAL_IP4_DNS and
INTERNAL_IP6_DNS attributes in its CFG_REPLY.
For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute, an
INTERNAL_DNSSEC_TA attribute may be included by the responder. This
attribute lists the corresponding DSSNEC trust anchor in the
presentation format of a DS record as specified in [RFC4034].
> MGLT: Maybe that would be good to have a INTERNAL_NS attribute.
> Also one domain name may have multiple TA, I think it would be
> wiser to be able to have multiple TA payload associated to one
> domain.
4. Payload Formats
4.2. INTERNAL_DNSSEC_TA Configuration Attribute
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ DNSSEC TRUST ANCHOR ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296].
o Attribute Type (15 bits) [TBD IANA] - INTERNAL_DNSSEC_TA.
o Length (2 octets, unsigned integer) - Length of DNSSEC Trust
Anchor data.
o DNSSEC Trust anchor (multiple octets) - The presentation format of
one DS record as specified in [RFC4034]. The TTL value MAY be
omited and when present MUST be ignored. The domain name is
specified as a Fully Qualified Domain Name (FQDN) - irrespective
of the presence of a trailing dot, and consits of a string of
ASCII characters with labels separated by dots and uses IDNA
[RFC5890] for non-ASCII DNS domains. The value is NOT null-
terminated.
> MGLT: I think that is better to use the wire format than the string
format.
> I do not understand why the TTL is ignored. I also think that
> would be important in case of KSK roll-over.
> Maybe some text could mention that multiple TA can be added
> especially during the key roll over.
> In addition, I think additional text shoudl be provided to clarify
> what ar ethe advanatges of using a DS reccord. In fact providing
> the KSK in stead of the DS prevent teh client to request the KSK....
> so it seems the KSK will anyway be transmitted.
5. Split-DNS Usage Guidelines
If a CFG_REPLY payload contains no INTERNAL_DNS_DOMAIN attributes,
the client MAY use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS
servers as the default DNS server(s) for all queries.
For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload, the client
SHOULD use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS
servers as the only resolvers for the listed domains and its sub-
domains and it SHOULD NOT attempt to resolve the provided DNS domains
using its external DNS servers.
> MGLT: This may come with some privacy issues. So I would rather
> let the client chose if the domain is in relation with an internal
> resolution.
If a CFG_REPLY contains one or more INTERNAL_DNS_DOMAIN attributes,
the client SHOULD configure its DNS resolver to resolve those domains
and all their subdomains using only the DNS resolver(s) listed in
that CFG_REPLY message. If those resolvers fail, those names SHOULD
NOT be resolved using any other DNS resolvers. All other domain
names MUST be resolved using some other external DNS resolver(s),
configured independently, and SHOULD NOT be sent to the internal DNS
resolver(s) listed in that CFG_REPLY message. For example, if the
INTERNAL_DNS_DOMAIN attribute specifies "example.com", then
"example.com", "www.example.com" and "mail.eng.example.com" MUST be
resolved using the internal DNS resolver(s), but "anotherexample.com"
and "ample.com" MUST be resolved using the system's external DNS
resolver(s).
> MGLT: Unless i am missing some point I would rather mention this as a
> SHOULD. This appears to me more a policy.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
