Subject: [IPsec] Comments to the draft-ietf-ipsecme-split-dns-04.txt

From: Tero Kivinen <[email-masked]>
Date: Tue, 6 Feb 2018 15:29:47 +0200

While approving the IANA allocations I re-read the document again, and
I have some more comments that might make the document more
understandable.

--

In section 4.1 there is example of example.com, but it would be better
to put quotes around it it, i.e., change

	A Fully Qualified Domain Name used for Split DNS rules, such
      as example.com, ...

with

	A Fully Qualified Domain Name used for Split DNS rules, such
	as "example.com", ...

as we do in the RFC7296 section 3.5 for ID_FQDN.

--

In section 4.2 there is "Digest Type" in the figure, but the
list has only item for "DS algorithm". Make those same.

--

It is bit misleading to say that "Key Tag", "Algorithm", "DS algoritm"
etc can either be 0 or 2/1/1 etc octets long. How does the receiver
know what is going to be the length of the "Key Tag" value for
example?

I assume the intent has been to say that either all the fields are
there with fixed lengths, or they are all omitted, meaning the length
is 0 for all of them.

The current section 4.2 does not clearly indicate that.

I would propose following change:

----------------------------------------------------------------------
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 Data                     ~
    |                                                               |
    +---------------------------------------------------------------+

   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 Data (0 or more octets) - Either empty or
      DNSSEC Trust Anchor data in format specified in the the
      [RFC4034] Section 5.1 (copied here for conveniency):

                        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
    +-------------------------------+---------------+---------------+
    |           Key Tag             |  Algorithm    |  Digest Type  |
    +-------------------------------+---------------+---------------+
    |                                                               |
    ~                            Digest                             ~
    |                                                               |
    +---------------------------------------------------------------+

   o  Key Tag value (2 octets, unsigned integer) - Key Tag as
      specified in [RFC4034] Section 5.1 

   o  Algorithm (1 octet) - DNSKEY algorithm value from the IANA DNS
      Security Algorithm Numbers Registry 

   o  Digest Type (1 octet) - DS algorithm value from the IANA
      Delegation Signer (DS) Resource Record (RR) Type Digest
      Algorithms Registry

   o  Digest (length specified by the Digest Type field octets) - The
      DNSKEY digest as specified in [RFC4034] Section 5.1 in
      presentation format. 

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

I.e., split the figure in two pieces, where first one just says we
have the DS RDATA inside (or not in case of request and then the
length is 0), and then explain the DS RDATA format after that...
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 6 Feb 2018 11:21:19 -0500 (EST)

> I have some more comments that might make the document more

Thanks!

> to put quotes around it it

Fixed in -05

> list has only item for "DS algorithm". Make those same.

Fixed.

> know what is going to be the length of the "Key Tag" value for

It was actually a mistake (partially induced by my memory of rfc-8078
work and its errata). Those fields are all fixed length. Only the digest
itself is variable length, and as per 8078 errata, the shortest
representation would be "00", so two octets.

> there with fixed lengths, or they are all omitted, meaning the length

That was not at all the intent :)

I've submitted -05. My only question now is what to do with the
length field of both records. It now says "2 octects, unsigned integer"
but perhaps it should say "2 octets in network order" ?

https://tools.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-05.txt

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 6 Feb 2018 20:04:11 +0200

> representation would be "00", so two octets.

That does not match the section 3.

I.e., in section 3 you have examples and text saying that initiator
will send empty INTERNAL_DNSSEC_TA attribute in CFG_REQUEST:

   To indicate support for DNSSEC, an initiator includes one or more
   INTERNAL_DNSSEC_TA attributes as defined in Section 4 as part of
   the CFG_REQUEST payload. If an INTERNAL_DNSSEC_TA attriute is
   included in the CFG_REQUEST, the initiator SHOULD also include one
   or more INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST.

   An initiator MAY convey its current DNSSEC trust anchors for the
   domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does
   not wish to convey this information, it MUST use a length of 0.

but this is not possible with current definition of the section 4.2,
where the DNSKEY Key Tag etc fields are mandatory. Thats why my
proposal was to make whole DNSSEC Trust Anchor Data optional. 

> but perhaps it should say "2 octets in network order" ?

In RFC7296 we have:

   All multi-octet fields representing integers are laid out in big
   endian order (also known as "most significant byte first", or
   "network byte order").

which covers everything. You could add similar text here... 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 6 Feb 2018 13:16:01 -0500 (EST)

> proposal was to make whole DNSSEC Trust Anchor Data optional.

Riiight...I forgot about the CFG_REQUEST item.

Ok, I will change it and list both versions in separate packet diagrams.

> which covers everything. You could add similar text here...

Thanks, will do.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 9 Feb 2018 12:06:37 -0500 (EST)

> proposal was to make whole DNSSEC Trust Anchor Data optional.

Fixed in -06

>   endian order (also known as "most significant byte first", or

Thanks, added to the start of the section.

diff at:

 	https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-06

Paul