[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: WG last call - TSIG




> On Fri, 18 Dec 1998, Stuart Kwan wrote:
> 
> > > Here are Brian Wellington's summary comments on Original ID in a message
> > > 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 master
> > > >server notices that the request ID and original request ID don't match,
> > > so
> > > >it must be a forwarded message, but since it's using the original reques
> 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 variable
> > > 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 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 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
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org