Re: FW: WG last call - TSIG

[marka@isc.org]

> On Sun, 20 Dec 1998 marka@isc.org wrote:
> 
> > 
> > > On Fri, 18 Dec 1998, Stuart Kwan wrote:
> > > 
> > > > > Here are Brian Wellington's summary comments on Original ID in a mess
> age
> > > > > dated 10/03/98:
> > > > > 
> > > > > >OK, what if an "original ID" field was added to the TSIG record and 
> the
> > > > > >digest?  It would be copied from the request ID by the client.  The
> > > > > >forwarder receives the message and resends it with a new ID.  The ma
> ster
> > > > > >server notices that the request ID and original request ID don't mat
> ch,
> > > > > so
> > > > > >it must be a forwarded message, but since it's using the original re
> ques
> > > t
> > > > > 
> > > > > >ID in the TSIG verification, it should be ok.  Its response sets the
>  
> > > > > >original id to the original request ID, and the meesage ID to the 
> > > > > >incoming message ID.
> > > > > 
> > > > > Section 3.4.1 seems to cover the behavior part of Brian's comment.
> > > > > However, Original ID is not included in section 3.4.2 as a TSIG varia
> ble
> > > > > included in the data to be digested.  Was this omission intentional? 
>  I
> > > > > can't decide if it's necessary or not.
> > > 
> > > 
> > >    3.4.1. DNS Message
> > > 
> > >    A whole and complete DNS message in wire format, before the TSIG RR ha
> s
> > >    been added to the additional data section and before the DNS Message
> > >    Header's ARCOUNT field has been incremented to contain the TSIG RR.  I
> f
> > >    the message is of a type that can be forwarded (i.e. update) and the
> > >    message ID differs from the original message ID, the original message 
> ID
> > >    is substituted for the message ID.
> > > 
> > > 
> > > The original ID is substituted for the header ID in cases where it
> > > differs.  It is an error if this occurs on a non-forwardable type.
> > > 
> > > Should the text be made clearer, or the process changed?  If there is
> > > going to be a change, I wouldn't mind seeing a new error code defined for
> > > this case (since the three specified don't cover it too well).
> > > 
> > > Brian
> > > 
> > > 
> > 	Brian you missed answering Stuart's query. Section 3.4.2 does not
> > 	list the original ID, **** below. Is this deliberate or is it an
> > 	over site?
> > 
> >     3.4.2 TSIG Variables
> > 
> >     Source       Field Name       Notes
> >     -----------------------------------------------------------------------
> -
> >     TSIG RR      NAME             Key name, in canonical wire format
> >     TSIG RR      CLASS            (Always ANY in the current specification)
> >     TSIG RR      TTL              (Always 0 in the current specification)
> >     TSIG RDATA   Algorithm Name   in canonical wire format
> >     TSIG RDATA   Time Signed      in network byte order
> >     TSIG RDATA   Fudge            in network byte order
> > ****TSIG RDATA   Original ID      in network byte order
> >     TSIG RDATA   Error            in network byte order
> >     TSIG RDATA   Other Len        in network byte order
> >     TSIG RDATA   Other Data       exactly as transmitted
> > 
> > 	I my opinion it should be added to the signature calculation not that
> > 	it makes any real difference other than the to the number of chunks
> > 	feed to the digester.
> > 
> > 	Mark
> 
> It was deliberate.  The original ID is digested as part of the DNS
> message.  tsig-06 said that when the message is digested, the id field
> in the header is zeroed out.  tsig-07 says that when the message is
> digested, the id field in the header is replaced by the original id field
> in the TSIG, if they differ.
> 
> So, the original id field doesn't need to be in the list of TSIG variables
> digested, since it's digested as part of the DNS message.  I suppose the
> original id could be digested with the TSIG variables and the header id
> zeroed out, but I liked this way better.
> 
> Brian
> 
> 
	Fine.  But this needs to be explicitly stated in and the ****'d line
	added to section 3.4.2. TSIG Variables otherwise confusion will
	arise.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org