Subject: RE: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 2 Mar 2006 13:07:43 -0600

IMHO, Please add proxy pruning too.

If It need to truncate  via/RR also, can we show in the body that
response is truncated one ??

Thx
Samir

-----Original Message-----
From: Scott Lawrence [mailto:[email-masked]] 
Sent: Thursday, March 02, 2006 6:55 AM
To: Srivastava, Samir [SC100:8826:EXCH]
Cc: [email-masked]
Subject: Re: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00

On Thu, 2006-03-02 at 03:40 -0600, Samir Srivastava wrote:

> 1.   Draft proposes 
>       "Any 483 response SHOULD be constructed with a message body of 
> type
>       message/sipfrag containing as much as possible of the SIP header
>       from the rejected request."
> 
>   A Proxy receives the request on UDP, and forwards on the TCP , when 
> it receives the response, message becomes more than 1300 bytes (If 
> complete req needs to be copied). Proxy doesn't have TCP transport to 
> send 483 with complete Message. It need to chop down some of the 
> headers. It will be good to provide some guidance on what headers to
chop down.
> Especially via chopping should be
> done at the last. It is obvious, better it is stated.
> 
> 2. What B2BUA / SBC will do, there purpose is topology hiding. They 
> will not provide the meaningful
>    guidance as MAX HOP COUNT is reached in the hidden network. It 
> needs to be mentioned somewhere
>    too. 

The latter is addressed in the Security Considerations section:

   4.  Security Considerations

   The proposed mechanism provides a means by which topology and some
   routing information about a set of SIP systems can be discovered.
   The mechanism is very similar to that provided for IP routing by the
   traceroute tool.

   Some systems may not want to expose as much information as is
   available in the full set of SIP request headers by returning them in
   the error response body.  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.

I suppose that if a system wanted prune the response to fit into 1300
bytes, the recommendation about what to trim would be the same.  If the
consensus is it wouldb be better to move that to a section of its own
and then reference it for both purposes, that would be an easy change.

<rhetorical_question>
When are we going to all just agree that reassembling UDP is essential
and get it done? 
</rhetorical_question>

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

_______________________________________________
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, 03 Mar 2006 10:24:34 -0500

> response is truncated one ??

I'm not sure that I understand your question.

If what you are asking is if there is something in the response that
tells the recipient it is not the complete set of headers, then the
answer is that at present there is not.

If you are asking whether or not it is ok to also remove some of the Via
and RR headers, then I would say that doing so would dramatically reduce
the utility of including anything; in fact, it might be worse than
returning nothing at all.

Or were you asking for something else?

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

---

From: Hans Persson <[email-masked]>
Date: Fri, 03 Mar 2006 16:38:21 +0100

> returning nothing at all.

I interpreted his question as asking whether it would be possible for
the recipient of the 483 to tell whether the returned set of headers was
complete or not. If Via/Route headers have been pruned, knowing this
would be much more important than if just User-Agent/Subject/etc has
been removed.

However, I still see a use for something like 

   SIP/2.0 483 Too many hops
   From: Sip Send <sip:[email-masked]>;tag=612f37e7
   To: sip:[email-masked]
   Call-Id: [email-masked]
   Cseq: 1 INVITE
   Via: SIP/2.0/TCP 10.1.1.20:40221
        ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f
   Content-Type: message/sipfrag
   Content-Length: whatever
   Date: Fri, 14 Oct 2005 15:27:47 GMT

   INVITE sip:[email-masked] SIP/2.0
   Record-Route: <sip:192.0.2.162:5080
        ;lr;a;t=612f37e7;s=96e09e8e8c93a8c60bf460029847f4b1>
   Via: SIP/2.0/TCP 192.0.2.162
        ;branch=z9hG4bK-42e47bba67559bd9a3da1934a70bbc37
   Via: SIP/2.0/TCP 192.0.2.162:5080
        ;branch=z9hG4bK-50d909f1209f7a820de85c7831846330
   Via: SIP/2.0/TCP 192.0.2.162
        ;branch=z9hG4bK-994f162bc179fb75093166fabbfd13c7
   Via: SIP/2.0/TCP 192.0.2.162:5080
        ;branch=z9hG4bK-708842ad6ea22f8fa6e39c503d3d803e
   X-Comment: Only top four Via headers preserved.

if the message size needs to be kept down. I'm not saying that X-Comment
is necessarily a kosher way to get that information across, but you get
the idea. If I want to figure out what happened to get where we ended
up, I need to send the same request again, but with a lower Max-
Forwards.

Hans

-- 
Hans Persson <[email-masked]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  +46 13 210877   http://www.ingate.com/

Private: <[email-masked]>  http://www.lysator.liu.se/~unicorn/

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 03 Mar 2006 17:41:42 -0500

> up, I need to send the same request again, but with a lower Max-

Yes, that's possible.  I wouldn't want to embed the indication in the
body itself; I think that introduces to much ambiguity (did someone on
the path send that X-Comment?).  

We could define a parameter for the Content-Type...

   Content-Type: message/sipfrag;truncated

It is probably important to specify that if you're going to remove any
Vias, Routes, or Record-Routes, that you always remove those that are
furthest from the system that is returning the error (closest to the
originator of the message).

---

From: Hans Persson <[email-masked]>
Date: Mon, 06 Mar 2006 10:31:12 +0100

> originator of the message).

It sounds wise to specify what's suitable to prune in order to be most
useful. 

Perhaps it would be possible to indicate somehow what (how many vias,
etc) was removed (at least for routing headers). On the other hand, that
assumes that nothing on the way back truncates the message further in
order for that information to be useful. It may be better not to go
there.

Servers that don't like to return information about local topology and
want to prune all routing headers could probably still return something
like "17 Vias and 2 Record-Routes pruned". The next question is whether
that would be more useful than just a regular empty 483.

Hans