Re: [dnsext] EDNS0 options open issues

[Alfred Hönes <ah@tr-sys.de>]

Folks,
I try to revive an almost non-existing discussion Olafur had started.

At Thu, 20 Nov 2008 08:04:14 -0500 , <ogud@ogud.com> wrote:
> ...
>
> Q1: How do we mark Ignorable vs Required options ?
> (see Section 4.4.2 of EDNS0-bis)
> The possibilities include:
>  a)  - Continue to define all options as ignorable
>  b)  - Set an ENDS0 flag (affects all options in message)
>  c)  - define a range of option numbers for required options
>  d)  - steal a bit from the option number to be set when
>        support for that option is required by recipient.
[letter tags added above for reference below -- A.H.]

> Q1-1: If we allow required options does that mean we need to go to
> a new EDNS version number?
>
> Q2: We are starting to see requests for EDNS options that are
> mostly "local scope" for MDNS/Bonjour should these be treated
> differently?
>
> Q3: What should the registration criteria for new ENDS0 Options be?
> Currently it is Standards track. RRtypes are Expert review.
> (Section 7 of ENDS0-bis)
>
> Feel free to add more open questions.
>
>     Olafur

(A)  Starting with the last point ...

Looking at other protocols with related issues, an additional
dimension for splitting the option number space might be the
'transparency' behavior:

One idea for Forgery_Resilience++ was an EDNS0 option (containing
additional entropy) to be echoed by the DNS server in the response
unchanged.  Other applications where some state/cookie information
would be needed back by the querier can be envisioned.

To allow the introduction of such options in the future without
causing the need to update DNS server software in such case,
a 'transparently pass back' flag bit could be defined.

Combined with 'Ignorable'/'Required', this would split the EDNS
option space into 4 distinct classes.


(B)  Back to the original questions

Q1)  I'm in favor of d) -- this method should be easy to implement
     and there are a couple of precedents for doing so (various
     Routing, Signaling, and AAA protocols, among others)
     -- and do d) again for the proposal above, if accepted.

     b) is inflexible and IMO not worth the effort.

     c) is comprised in d) but -- in its general form --
        more complicated.

Q1-1) IMO, introduction of this classification deserves a clear cut,
     i.e., one-shot inrement in the EDNS version.
     Otherwise, backwards compatibility issues will like cause a
     nightmare for protocol design and implementers.

     Support of any new EDNS option in a resolver needs an update
     of the resolver software anyway; thus, requiring this single
     step will not be detrimental for resolver software.
     For server software, support of new behavior will necessitate
     an update for new 'Required' options anyway; thus the same
     arguments apply in this case.  The more 'generic' behavior
     can be defined (cf. (A) above), the more useful will be
     (the first) such update even for other option class(es).

Q2)  The underlying hypothesis for this question seems to be
     questionable.
     Independently, I do not see a specific need to make that
     distinction now.  (PoV might have to be reconsidered if
     use case come up demonstrating real need.)

Q3)  This question should be addressed when the new framework
     is defined and has sufficient consensus to proceed.

     I.e., if the consensus for Q1 ends up with answer a),
     that indeed should happen soon, but I expect that this
     will not be the case.


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>