Subject: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt

From: [email-masked]
Date: Fri, 02 Jun 2006 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Diagnostic Responses for SIP Hop Limit Errors
	Author(s)	: S. Lawrence, et al.
	Filename	: draft-ietf-sip-hop-limit-diagnostics-02.txt
	Pages		: 12
	Date		: 2006-6-2
	
The SIP protocol imposes a limit on the number of hops a request may
make from a sender to the recipient.  When this limit is reached, a
483 error response is returned.  The present form of the 483 response
does not provide enough information for the sender or proxies on the
path to diagnose failures whose symptom is that the hop limit is
reached.  This document proposes additional diagnostic information to
be returned in a 483 response.

Comments are solicited, and should be directed to the SIP working
group list at [email-masked]'.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-hop-limit-diagnostics-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-hop-limit-diagnostics-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-hop-limit-diagnostics-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 02 Jun 2006 16:36:02 -0400

> be returned in a 483 response.

I believe this version addresses all the comments received on the -00
draft (which was actually the second publication; the first was part of
the SIPPING draft draft-lawrence-maxforward-problems-00.txt).  

Specifically, it:

- Adds a Warning header to identify the system at which the hop limit
was reached.

- Provides a suggested way to trim the returned message, should that be
needed for size or security reasons.

(the difference between -01 and -02 was just an editorial error in the
author contact information)

Other than the issues addressed above (which were both good
suggestions), this has, I think, been non-controversial.  I believe that
it is ready for a Working Group Last Call.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Architect             - Pingtel Corp. http://www.pingtel.com/

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 08 Jun 2006 15:23:13 -0400

Here are some comments on this, broken into major and nits:

MAJOR:

* Seems like this specification would also be useful in cases of 482 
(loop detected as opposed to max-forwards exceeded). Should we expand to 
include that?

* from rfc4485, you need to have sections that more clearly spell out 
the behavior expected for a UAC, UAS and proxy.

* Indeed, I think a UAC needs ot include a message/sipfrag in the Accept 
header field of a request it sends so that the entity generating the 483 
knows that this type is accepted

NITS:

* expand SIP acronym in title

* the document says it 'updates' rfc3261 but its not clear to me it does 
that; are you saying its doing that because its changing the usage of 
Warning?

* abstract: expand first instance of SIP

> .  Diagnosing Hop Limit Exceeded Failures
> 

expand SIP acronym

> When a SIP User
>    Agent receives a request whose Max-Forwards is zero, it returns a 483
>    error response to indicate that the limit was reached.

this can happen at a proxy too

> The 483 response alone does not provide enough information, for the
>    sender to determine where the problem lies.

extra comma

> In the authors
>    experience, the problem is rarely that the target of the request was

Suggest removing 'in the authors experience' - OK to do this in an I-D, 
but as an RFC its a community document and such terms don't make as much 
sense.

> In practice, there is too little information returned in a 483
>    response for it to be of much use as a diagnostic. 

diagnostic tool

>  has traversed a series of proxies, the response follows the Vias back
>    to the requester; in the case of a typical 483 response it can be
>    difficult to determine even what server the response came from.  

Its more than difficult; there is nothing in the response which says 
where it came from.

> As an aid to diagnosing problems that result in 483 responses, it
>    would be useful to know how the failed request arrived at the
>    rejecting system; both what path it followed to get there, and what
>    the request looked like when it ran out of hops. 

I think this is supposed to be a dash and not a semicolon.

* I recommend that you move the example in 2.3 to a separate Example 
section at the end of the draft, consistent with the general way we've 
been doing our specs with the example in a section at the end

> It is suggested in this case that at least all of the Route and Via
>    headers from the request be returned in the message/sipfrag body.  In
>    the example (Section 2.3), this would at least enable the end user to
>    determine which proxies were in the routing loop and how the request
>    arrived there, but not the specific address transformations that
>    caused the loop.

should use SHOULD here

* section 3 is good to hear but probably doesn't belong in the final 
published rfc

Thanks,
Jonathan R.

[email-masked] wrote:

> ------------------------------------------------------------------------
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 08 Jun 2006 16:02:11 -0400

> (loop detected as opposed to max-forwards exceeded). Should we expand to 

I think that would be a good idea.  Are there other errors relevant to
message route diagnosis that would also be good?

> the behavior expected for a UAC, UAS and proxy.

I'm not sure I understand what you think is missing.  This does not
actually define any new header fields, parameters, or body types; it
just specifies more clearly how to return useful information using
existing mechanisms for an existing error type.

> knows that this type is accepted

My interpretation is that the Accept header field describes what the UAC
wants in a successful response, and is not needed for the (that's why I
quoted 3261 in section 2.2 of the draft:

      RFC 3261 (section 7.4) says: "All responses MAY include a body.".

I've been testing this for nearly two years, and have never had a
problem with a UA getting this back, except for those that can't
assemble fragmented UDP.

> * expand SIP acronym in title

ok

> that; are you saying its doing that because its changing the usage of 

No, because it adds a new SHOULD for how to construct the error
response.  I don't think that it does change Warning.

> this can happen at a proxy too

Would "any SIP implementation" be better than "a SIP User Agent"?

> >    sender to determine where the problem lies.

thx

> >    response for it to be of much use as a diagnostic. 

agreed.

> * section 3 is good to hear but probably doesn't belong in the final 

ok.  If that is removed, then just swapping the section on "Pruning
Responses" section and "Example" makes the latter last as you suggest...

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 09 Jun 2006 10:55:12 -0400

inline.

> message route diagnosis that would also be good?

I would actually argue that, for any non-recoverable error generated by 
a *proxy*, you might find these useful. In other words, a 407 is 
excluded, since thats clearly recoverable. But if a proxy generates a 
513 (message too large), the diagnostic information would be helpful to 
figure out what proxy it was that gave you this problem.

> existing mechanisms for an existing error type.

I understand it doesn't define any new headers or anything, but it does 
specify new behaviors of SIP entities, and you need to clearly call them 
out. RFC 4485 recommends a breakdown like this:

1. Proxy Behavior

2. UAC Behavior

3. UAS Behavior

I'd advise that the proxy behavior section basically say that you SHOULD 
include this information in a body, and describe the rules for trimming 
when its too large, and which header fields to include in the sipfrag. 
The UAC section should probably talk about Accept header (pending 
discussion below) and what to do with the body that comes in the response.

> problem with a UA getting this back, except for those that can't

Hmm, I find no text in either RFC 3261 or 2616 which would indicate 
whether Accept applies to error responses or not. I don't have a big 
problem with sending it anyway, but the spec should call out that this 
would be done regardless of the Accept value and thus the body may not 
be understood by a UAC.

> response.  I don't think that it does change Warning.

I view it as an extension, not an update, but maybe its splitting hairs.

> Would "any SIP implementation" be better than "a SIP User Agent"?

Server is the appropriate term, as it covers UAC and proxy.

> Responses" section and "Example" makes the latter last as you suggest...

Per above the prunign should go in a section on proxy behavior.

-Jonathan R.

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 09 Jun 2006 15:48:31 -0400

> figure out what proxy it was that gave you this problem.

I agree.  Adding text to that effect will probably add fuel to the issue
of how 'Accept' works...  see below.

> discussion below) and what to do with the body that comes in the response.

I can certainly rearrange it that way.  There have already been enough
changes based on the WGLC to justify a respin as soon as the comment
rate falls off (I'll do one before the ID cutoff for Montreal in any
event at this point).

> would be done regardless of the Accept value and thus the body may not 

I admit that I didn't look hard before writing this draft - my
presumption that it is ok came from my HTTP background.  I could argue
that RFC 2616 (HTTP 1.1) _does_ spell this out (in section 10.4.7 406
Not Acceptable):

      Note: HTTP/1.1 servers are allowed to return responses which are
      not acceptable according to the accept headers sent in the
      request. In some cases, this may even be preferable to sending a
      406 response. User agents are encouraged to inspect the headers of
      an incoming response to determine if it is acceptable.

and that RFC 3261 says, in section 20.1 Accept:

   The Accept header field follows the syntax defined in [H14.1].  The
   semantics are also identical, with the exception that if no Accept
   header field is present, the server SHOULD assume a default value of
   application/sdp.

Whether or not the exception in 3261 invalidates the liberality of 2616
may be controversial.

My reading of the discussion I do find on Accept usage in 3261 is all
focused on either: how it is used in a request to restrict what is
acceptable in a session, or how to reject something and communicate what
would have been ok.  All of that is focused on UAs, because proxies are
explicitly assumed to be agnostic with respect to methods and bodies.

I would not have a problem with putting in a section to clarify this
point (of course, I'd want to do it with the liberal HTTP-ish
interpretation that servers can do whatever they want as long as they
understand that it may not work).  I feel a wider discussion coming
on... if so, I suggest that it get a thread with a title that will draw
more eyes...

> I view it as an extension, not an update, but maybe its splitting hairs.

I'll defer to the process lawyers on this...

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 9 Jun 2006 21:18:08 -0700

On Jun 9, 2006, at 7:55 AM, Jonathan Rosenberg wrote:

>
>>> * the document says it 'updates' rfc3261 but its not clear to me  
>>> it does that; are you saying its doing that because its changing  
>>> the usage of Warning?

I think it is an extention not an update.

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 12 Jun 2006 09:25:29 -0400

> I think it is an extention not an update. 

Thinking about this further over the weekend, I don't think I agree.  I
don't care enough - I'll take the 'updates' off the next rev of the
draft if there is rough consensus, but I thought it worth pointing out
why I used 'updates':

- this introduces new normative behavior for all Servers

- the new behavior is not controlled or advertised using the mechanisms
for identifying extensions (Supported/Requires).

The advantage of using the 'updates' attribute is that the RFC Editors'
document index entry for 3261 will have the pointer to the new spec,
informing any future reader that there is something more to read...

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Jun 2006 21:40:10 -0400

inline.

>       an incoming response to determine if it is acceptable.

Ah. I had missed this bit in RFC 2616. I had read only the definition of 
Accept and didn't find it there.

> Whether or not the exception in 3261 invalidates the liberality of 2616

At the very least, its not clear.

> on... if so, I suggest that it get a thread with a title that will draw

I'm fine with the more liberal approach. It just needs to be clarified.

-Jonathan R.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Jun 2006 17:15:35 -0700

> for identifying extensions (Supported/Requires).

If both of these are true, I agree with you. But I don't see why this  
draft would need both of these. I see no reason this can not be  
optional behavior.  Anyways, this is a nit, the serious issues in the  
draft has to do with the size of the responses.

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 20 Jun 2006 11:27:00 -0400

On Mon, 2006-06-19 at 17:15 -0700, Cullen Jennings wrote:
> draft would need both of these.

I'm not sure I understand what you mean.  It introduces a new SHOULD.
It does not specify any related feature/option tag.  If you think either
of these statements need to be changed, say how and why.

>  I see no reason this can not be optional behavior. 

I generally prefer to make everything mandatory that is not forbidden.
Optional behavior is harmful to interoperability and confusing to
implementors.

>  Anyways, this is a nit, the serious issues in the  

Do you have some suggestion with respect to that?

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 20 Jun 2006 23:06:07 -0700

> Optional behavior is harmful to interoperability and confusing to

I am suggesting that you say that servers that support this RFC need  
to do this and let servers decide if they want to support it or not.  
This is comparable to say REFER. You will note that REFER does not  
update 3261. A device can decide if it wants to implement this or  
not. Perhaps I misunderstood your intent and you are saying that  
everything that does 3261 should have to implement this.

> Do you have some suggestion with respect to that?

Yes - I believe the magic number we agreed on for UDP was something  
close to 1200. You need to say that if any of the hops used UDP, the  
response MUST NOT be larger than 1200 octets. You then need to show  
some scheme for a making the response smaller than this. In a typical  
example with default max hops, I really don't see how this will be  
possible. I've be very interested in seeing how large a typical  
example that had the full trace in from actually is. I know this is  
not very satisfying - I hope some can think of a better way to solve  
this but I'm not coming up with one.

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 21 Jun 2006 14:03:55 -0400

> everything that does 3261 should have to implement this.

Yes, that is my intent.  

A new method does have a defined mechanism for signaling whether or not
it is implemented, so it counts as an extension, not an update.

> this but I'm not coming up with one.

Well, I didn't cite the number mostly because it's already provided
elsewhere and I saw no need to duplicate either the number or the
requirement that the response be under that limit.  If you can point to
where that rule is clearly stated in an existing spec, then I think a
reference to it would be good (I hate it when every document repeats
rules already stated in some other document - this should be 'updates',
not 'obsoletes').

I did describe how the response should be trimmed to get it under
whatever limit the implementation wants to get it under.

I'm not particularly interested in examples with the default max hops if
by that you mean 70.  I think that number is way too large, and I doubt
there are many deployed proxies that would pass it (all the proxies we
used at SIPit to explore the forking amplification attack clipped
Max-Forwards to 20, if I recall), and I'd bet there are no real calls
that would need it and actually work.  Forget whether or not the error
response would fit in 1200 bytes - the request wouldn't.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 21 Jun 2006 11:55:16 -0700

inline

> rules already stated in some other document - this should be  

I had the number wrong but have a look at section 18.1.1 of RFC 3261.  
I think it is good to point out to implementers that they need to  
meet this and how they might do it. I agree we don't want this draft  
redefining

> response would fit in 1200 bytes - the request wouldn't.

Well, if you think the default Max-Frorwards needs to be changed, you  
likely need to start a thread on that. My experience on deployed  
systems has certainly not been that it always get's clipped to 20.

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 21 Jun 2006 15:33:51 -0400

> meet this and how they might do it. I agree we don't want this draft  

Section 18.1.1 is on sending requests, not responses.  I don't find
anything in the sections on responses about requiring that they be below
any particular size.  Even if I am responding positively and sending
SDP, on a long path my response may (often will) exceed the 1300 byte
limit for requests, but if I follow the rules in 18.2.2 on sending
responses I may find myself sending UDP that will fragment.  I am not
particularly interested in arguing that there should be such a limit,
but if there is one in current requirements, I'm happy to cite it.