Subject: Error codes and SIG(0)

From: "Scott Rose" <[email-masked]>
Date: Thu, 7 Aug 2003 13:21:24 -0400

This is a part of the SIG(0) updating draft that is kind of an open
question.  In the current RFC 2931, there is no error code (like in TSIG)
returned to the client when an error occurs.  This is also an issue in
draft-stjohns-secure-notify-00.txt when talking about error codes to return
when using SIG(0)'s as part of the notify message.

Is there a need to have some sort of error code returned when using SIG(0)?
This could be the same codes as used with TSIG (BADSIG, BADTIME), with a
slight variation in meaning.  Probably with never having a return signed
with a SIG(0) (to prevent an easy DoS attack).  It would just return the
error response without a SIG(0).

The first question to ask ourselves is whether or not there needs to be text
on error return codes for SIG(0) errors.

Scott

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

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 8 Aug 2003 09:00:30 -0400

Another option would be to re-allocate a field in the SIG(0) RDATA to act as
the same extended error code field in the TSIG RDATA.  There are a few "left
over" fields in the SIG(0) to do this, as they were part of the original SIG
RR.

In that case, the returning an error from a SIG(0) would be more like
returning an error in TSIG.  That is, there would be a SIG(0) RR at the end
of the response without the actual signature field, and the error code set
to some value.

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 07, 2003 5:15 PM
Subject: Re: Error codes and SIG(0)

> > However, there seems to be a problem.  The TSIG extended rcode values
are
> > stored in the TSIG, while the "extended RCODE" value is in the OPT RR.
> > According to the IANA database, both have reserved the code 16 for
BADVERS
> > and BADSIG.  There is no space for an extended rcode value in the SIG(0)
RR,
> > unless the spec is changed to give remap a field to that purpose.
> >
> > Or else the two competing rcode assignments be reconciled somehow.
>
> the original edns proposal had a major and a minor version number, with
> the intent that minor version numbers could indicate understanding of
> (and therefore an implicit solicitation of) more OPT's without changing
> the encoding format of anything in the opt-rdata.  this got taken out,
> and our only method of indicating an initiator's ability to understand
> a new OPT (like an extended error code blob) would be to negotiate a
> higher edns version number.  this seems like overkill, but could be done.
>
> --