[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG last call: ENDS0
Kre;
> We now have support for almost every reasonable choice here... Can we have
> more opinions from others please?
I think reality checks work better thaFrom owner-namedroppers Sun Dec 20 01:43:18 1998
Received: by opsmail.internic.net (8.9.1/8.9.1) id BAA17365
for namedroppers-outgoing; Sun, 20 Dec 1998 01:31:43 -0500 (EST)
Received: from rs.internic.net (biprrs5.lb.internic.net [192.168.120.43])
by opsmail.internic.net (8.9.1/8.9.1) with SMTP id BAA17359
for <namedroppers@internic.net>; Sun, 20 Dec 1998 01:31:42 -0500 (EST)
Received: (qmail 26977 invoked from network); 20 Dec 1998 06:31:41 -0000
Received: from slam.internic.net (198.41.0.36)
by 192.168.119.43 with SMTP; 20 Dec 1998 06:31:41 -0000
Received: (from markk@localhost)
by slam.internic.net (8.8.8/SLAM-2)
id BAA29402 for namedroppers@internic.net; Sun, 20 Dec 1998 01:31:40 -0500 (EST)
Received: from rs.internic.net (biprrs3.lb.internic.net [192.168.120.41])
by opsmail.internic.net (8.9.1/8.9.1) with SMTP id AAA07755
for <namedroppers@internic.net>; Sun, 20 Dec 1998 00:32:49 -0500 (EST)
Received: (qmail 5962 invoked from network); 20 Dec 1998 05:32:48 -0000
Received: from relay.hq.tis.com (192.94.214.100)
by 192.168.119.41 with SMTP; 20 Dec 1998 05:32:48 -0000
Received: by relay.hq.tis.com; id AAA01417; Sun, 20 Dec 1998 00:39:09 -0500 (EST)
Received: from spiral.hq.tis.com(10.33.40.46) by relay.hq.tis.com via smap (4.1)
id xma001405; Sun, 20 Dec 98 00:38:37 -0500
Received: from localhost (bwelling@localhost)
by spiral.hq.tis.com (8.8.7/8.8.7) with ESMTP id AAA15298;
Sun, 20 Dec 1998 00:29:59 -0500
X-Authentication-Warning: spiral.hq.tis.com: bwelling owned process doing -bs
Date: Sun, 20 Dec 1998 00:29:59 -0500 (EST)
From: Brian Wellington <bwelling@TIS.COM>
X-Sender: bwelling@spiral.hq.tis.com
To: marka@isc.org
cc: Stuart Kwan <skwan@MICROSOFT.COM>,
"'namedroppers@internic.net'" <namedroppers@internic.net>,
"'Robert Elz'" <kre@MUNNARI.OZ.AU>
Subject: Re: FW: WG last call - TSIG
In-Reply-To: <199812192346.KAA27483@bsdi.dv.ipdev.com>
Message-ID: <Pine.LNX.4.05.9812200023350.15143-100000@spiral.hq.tis.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-namedroppers@internic.net
Precedence: bulk
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 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
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