A Negative Acknowledgement Mechanism for Signaling Compression
draft-ietf-rohc-sigcomp-nack-02

Answer given to IANA, Narten who wanted registry for error codes:

Date: Thu, 16 Dec 2004 15:13:27 -0600
From: Adam Roach
To: iesg@ietf.org


Addressing Thomas' concern, which was echoed by Michelle:

> IANA considerations: what about future registration of Reason Codes?
> Should a registry be set up? If so, what is the policy for future code
> registrations?


In short, I think the answer is: we need no such registry.

Part of the development of this document included an attempt to capture
every possible error situation possible in RFC3320. I'll note that NACKs
are sent only in response to decompression failures, and are not
general-purpose error indications.

RFC3320 is very explicit in calling out what conditions can lead to
decompression failures. Quite simply, if a set of circumstances isn't
detailed as a decompression failure in RFC3320, then it can't get
reported in a NACK. By the working group's analysis, for version 0x02 of
SigComp (defined in the draft being discussed), there are precisely 25
things that can go wrong.

This list of errors, then, can not change unless and until a new version
of SigComp is issued. If you consider the NACK codes to be scoped to the
version of SigComp being used, then the need for a registry disappears.

To put it another way: the question of whether we need for a registry
for these error messages is precisely the same question as whether we
need for a registry of UDVM opcodes. The model of SigComp is that any
new opcodes necessitate a new SigComp version. Extending this property
to error codes is trivial, since new errors cannot arise unless the
SigComp functionality is extended.

/a

Answer given to IANA, Narten who wanted registry for error codes:

Date: Thu, 16 Dec 2004 15:13:27 -0600
From: Adam Roach
To: iesg@ietf.org


Addressing Thomas' concern, which was echoed by Michelle:

> IANA considerations: what about future registration of Reason Codes?
> Should a registry be set up? If so, what is the policy for future code
> registrations?


In short, I think the answer is: we need no such registry.

Part of the development of this document included an attempt to capture
every possible error situation possible in RFC3320. I'll note that NACKs
are sent only in response to decompression failures, and are not
general-purpose error indications.

RFC3320 is very explicit in calling out what conditions can lead to
decompression failures. Quite simply, if a set of circumstances isn't
detailed as a decompression failure in RFC3320, then it can't get
reported in a NACK. By the working group's analysis, for version 0x02 of
SigComp (defined in the draft being discussed), there are precisely 25
things that can go wrong.

This list of errors, then, can not change unless and until a new version
of SigComp is issued. If you consider the NACK codes to be scoped to the
version of SigComp being used, then the need for a registry disappears.

To put it another way: the question of whether we need for a registry
for these error messages is precisely the same question as whether we
need for a registry of UDVM opcodes. The model of SigComp is that any
new opcodes necessitate a new SigComp version. Extending this property
to error codes is trivial, since new errors cannot arise unless the
SigComp functionality is extended.

/a

IANA Comments:  It is now clear that the registration will
go in the following:

Also saw comment from Thomas' regarding Reason Codes.  Good catch.
IANA needs to know what to do there.  It seems that a registry
should be set-up and registrations procedures established in this document.

[Ballot discuss]
IANA considerations: what about future registration of Reason Codes?
Should a registry be set up? If so, what is the policy for future code
registrations?

I'd like to be sure that WG has thought about this issue.

[Ballot comment]
Reviewed by Lucy Lynch, Gen-ART

Her review:

This draft is ready for publication as a Proposed Standard RFC

Note that it has a few small nits (see below) and some odd pagination
issues but the document is very well written. The case for NACK is clearly
explained and the draft has seen good discussion and review on the rohc
list and the updates listed at the end of the document reflect the
evolution of the draft and fairly represent the issues raised. See for
example: http://www1.ietf.org/mail-archive/web/rohc/current/msg02541.html

Some of the phrasing can be a bit stilted:
"Detection of support for the NACK mechanism may be beneficial in some
certain circumstances.  For example, with the current definition of
SigComp, acknowledgment of state receipt is required before a sender
can reference such state."
but the intention is clear.
----------------------------------------------------------------------
idnits 1.51:

draft-ietf-rohc-sigcomp-nack-02.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html:

    Checking conformance with RFC 3667/3668 boilerplate...
    the boilerplate looks good.
    There are 558 instances of lines with non-ascii characters in the
    document.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:

    The document seems to lack a 1id_guidelines paragraph about the list
    of current Internet-Drafts -- however, there's a paragraph with a
    matching beginning. Boilerplate error?

  Miscellaneous warnings:

  There are 1 instance of lines with hyphenated line breaks in the
  document.

IANA Last Call Comments:  In the IANA Considerations section, there is a request for registration of "SigComp version 2 (NACK support)".  In which registry should this go?

[Ballot comment]
Sigcomp normally runs over the application transport.  However this
mechanism provides a case where a sigcomp nack message is sent over a
UDP transport under the sigcom implementation's control rather than
the application transport.

I'm concerned about the security implications of this layering change,
particularly when application confidentiality/integrity is deployed
along with sigcomp.  Previously all messages would go through the
application security layer, but now, some messages will be sent by the
sigcomp implementation directly and thus will not use any security
framing. 

This does give an attacker unencrypted sha-1 hashes of security
protected sigcomp messages.  I don't think that is a serious
vulnerability.

I haven't been able to find anything more serious than the leakage of
hashes.  If I did, this would be a discuss not a comment.  I'm still a
bit concerned though.

Adam's response to Ted's discuss:


There are two ways that this can be done: listening at that port *instead* of the port from which you sent it, or listening at that port *in addition* to the port from which you sent it.

The approach of listening to that port instead of the one from which you sent it is that you can end up with interoperability problems.

Let's say that, for protocol X, implementor A decides that he's going to listen to the port from which he's sending, even though responses for the protocol, as defined in its base specification, come to a different well known port. (As an aside, I'm having a hard time coming up with an example of a protocol that does this, but I'll continue). Why would he do this? Maybe he's aware of some newer extensions that allow the message itself to specify a different port for responses for the purpose of NAT traversal. It's a reasonable design choice.

Implementor B, on the other hand, reads the base specification, isn't aware of the NAT traversal extensions, and decides that he'll always send NACKs to the well known response port, instead of the port from which the request came. It's a reasonable design choice.

Of course, if implementor A's implementation tries to talk to implementor B's implementation, it simply doesn't work.

I think that's a realistic scenario of what may occur if we add language allowing implementations to listen to a protocol response port *instead* of the port from which they are sending messages. I don't think this is what you were proposing, but I wanted to make certain that all parties to this conversation understand that it is not a feasible approach.

The other alternative -- requiring that implementations listen at a response port *in addition* to the port from which they are sending messages -- has no immediately evident gains, while potentially imposing additional implementation complexity on implementors. Listening for the NACKs on multiple ports isn't the additional complexity that I'm referring to; it's having to add an interface that interacts with the application upon receipt of an uninterpretable message. Note that receipt of an uninterpretable message currently gives the SigComp stack no reason to pester the application at all. If we were to allow the application to specify an alternate location for NACKs, the SigComp stack would have to add these hooks to query the application, and the application would have to implement additional code to handle such queries.

So, in terms of harm to the protocol, I think the answer is: no, allowing responses to come to either the port from which they came or a port that the application can specify would not, in itself, be a problem.

However, unless there is both:

  1. an existence proof of a protocol for which the response port
    differs from the port from which requests are sent *and* which can
    be authoritatively known by the remote application, and

  2. some concrete benefit of allowing NACKs to come to that port
    instead of the port from which the request is sent,

it would be my strong recommendation that we do not add the complication of allowing such behavior.

/a

[Ballot discuss]
In section 2.2 the draft says:

  For a connectionless transport, such as UDP, the NACK message is sent
  back to the originator of the failed message at the port and IP
  address from which the message was sent.  Note that this may or may
  not be the same port on which the application would typically receive
  messages.  To accommodate implementations that use connect() or
  similar constructs, the NACK will be sent from the IP address and
  port to which the uninterpretable message was sent.  From a practical
  perspective, this is probably easiest to determine by binding
  listening sockets to a specific interface; however, other mechanisms
  may also be employed.

      The behavior specified above is strictly necessary for any
      generally useful form of a NACK mechanism.  In the most general
      case, when an implementation receives a message that it cannot
      decompress, it has exactly three useful pieces of information: the
      contents of the message, an indication of why the message cannot
      be decoded, and the IP address and port from which the message
      originated.  Note that none of these contains any indication of
      where the remote application is listening for messages, if it
      differs from the sending port.

Would there be any problem with allowing the NACK to be sent to an
IP address and port known to the application, where the application
layer has knowledge of where the remote application is listening?  This might
not be generally available (since not all applications would have
any way of accurately knowing this information), but I wonder if
it should actually be a protocol error to send it there rather than the
source ip and port in those cases where an application has this information.