Re: [DNSOP] draft-ietf-dnsop-rfc2845bis-01

Francis Dupont <Francis.Dupont@fdupont.fr> Sat, 17 November 2018 14:11 UTC

Message-Id: <201811171334.wAHDYwX2010336@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: Mark Andrews <marka@isc.org>
cc: dnsop <dnsop@ietf.org>
In-reply-to: Your message of Wed, 31 Oct 2018 11:14:57 +1100. <820E2C62-E806-4875-9E6C-9301A510980B@isc.org>
Date: Sat, 17 Nov 2018 14:34:58 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FQ05jacK98LjNWlhHArqii8hke0>
Subject: Re: [DNSOP] draft-ietf-dnsop-rfc2845bis-01
Precedence: list

 In your previous mail you wrote:

>  The setting of the time fields on BADKEY is not well defined.  We had implem
>  entations setting the values to zero. Handling of BADKEY with a bad time is 
>  also not handled well.  I would recommend always copying the time fields fro
>  m the request to the response for BADKEY and BADALG.  This provides the clie
>  nt with some of off path spoof protection.

=> BADALG does not exist: it is part of BADKEY.

>  The request'salgorithm field was not always copied to the response on BADKEY
>  .

=> I believe you mean the "algorithm name" field. I am adding in th 02
version this text:

          Algorithm name and
      	  time signed and fudge fields SHOULD be copied tothe response
      	  to provide off path spoof protection.

in the paragraph about BADKEY error generation.

>  There were various implementations that detected BADKEY but continued proces
>  sing the query.
>  NOERROR+BADKEY and REFUSED+BADKEY were seen.

=> IMHO it is incorrect and can't be fixed in RFC 2845 bis...

>  The ID field in the TSIG of the reply to a forwarded message is not well def
>  ined.  i.e. should it be the original ID from the requestâs TSIG or the ID of  the forwarded message.

=> Perhaps the 5.4.1. DNS Message section should be clarified. Do you have
some text to propose? Note the current text is:

5.4.1.  DNS Message

   A whole and complete DNS message in wire format, before the TSIG RR
   has been added to the additional data section and before the DNS
   Message Header's ARCOUNT field has been incremented to contain the
   TSIG RR.  If the message ID differs from the original message ID, the
   original message ID is substituted for the message ID.  This could
   happen when forwarding a dynamic update request, for example.

>  While other data in the initial request is not expected with RFC2845 it shou
>  ld be hashed but otherwise ignored if non empty.

=> I believe the current text is pretty clear about what is included in
the hash processing.

>  There are also some STD13 issues see like returning FORMERR is not done by t
>  aking the query and setting the RCODE=FORMERR and setting QR=1.

=> again is there some proposed text?

Thanks

Francis.Dupont@fdupont.fr

PS: if there is no other change request I'll submit the 02 version with
the update cited here next Monday.

Re: [DNSOP] draft-ietf-dnsop-rfc2845bis-01 Mark Andrews
Re: [DNSOP] draft-ietf-dnsop-rfc2845bis-01 Francis Dupont