Subject: [Sip] Comment/question on draft-ietf-sip-body-handling-01.txt

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 Mar 2008 09:45:05 -0400

At one of the recent IETF's, there was a session on SIP interop issues.  One of the issues we've found is different expectations about SIP header length and body size support.  We have found some implementations sending rather large bodies, where "rather large" is greater than 1MB.  Ignoring the reasons some middleboxes have policies to block such large bodies, the reason they have such policies is because lots of devices simply can't handle them.  There are other issues with it too, such as head-of-line blocking and inability to send it on over UDP.

So my question is, is it appropriate for a draft such as draft-ietf-sip-body-handling-01.txt to potentially define a maximum, or at least guidance about it?  It doesn't have to say one cannot send something larger - just say that receivers should only be expected to accept up to X byte large bodies.  I know this is an unpleasant topic, but it's causing interop issues which are causing certain SIP uses to fail in the real world.

-hadriel
_______________________________________________
Sip mailing list  https://www.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: Adam Roach <[email-masked]>
Date: Thu, 13 Mar 2008 09:45:25 -0400

[private response]

What? Without naming names, what methods are people attaching 1MB+ 
bodies to? And why?

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 Mar 2008 10:00:09 -0400

NOTIFY, for xml presence buddy-lists apparently, and MESSAGE with instant-message picture bodies.  1MB is the unusual case, but happens, whereas greater than 64KB is more common and also a problem (tough for a proxy to forward it over UDP).

-hadriel

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]]
> Sent: Thursday, March 13, 2008 9:45 AM
> To: Hadriel Kaplan
> Cc: [email-masked] List
> Subject: Re: [Sip] Comment/question on draft-ietf-sip-body-handling-01.txt
>
> [private response]
>
> > At one of the recent IETF's, there was a session on SIP interop issues.
> One of the issues we've found is different expectations about SIP header
> length and body size support.  We have found some implementations sending
> rather large bodies, where "rather large" is greater than 1MB.  Ignoring
> the reasons some middleboxes have policies to block such large bodies, the
> reason they have such policies is because lots of devices simply can't
> handle them.  There are other issues with it too, such as head-of-line
> blocking and inability to send it on over UDP.
> >
> > So my question is, is it appropriate for a draft such as draft-ietf-sip-
> body-handling-01.txt to potentially define a maximum, or at least guidance
> about it?  It doesn't have to say one cannot send something larger - just
> say that receivers should only be expected to accept up to X byte large
> bodies.  I know this is an unpleasant topic, but it's causing interop
> issues which are causing certain SIP uses to fail in the real world.
> >
> > -hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Mar 2008 09:58:15 -0400

> [private response]

Heh. Okay, so I botched that. Sorry.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Mar 2008 13:33:20 -0400

Hadriel,

I'm reluctant to make any blanket statement about this. I think it is 
very dependent on the context and the method.

I think this would be better in some sort of best practices document, if 
at all.

	Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 17 Mar 2008 10:49:31 -0500

Paul/Hadriel,

> I think this would be better in some sort of best practices document, if

My understanding is that Paul is saying that we should not have normative 
text that says something like "MUST NOT send headers/bodies larger than 
$SOME_VALUE". I would agree with that.

I believe that capturing guidance in a best practices document would be 
useful.

Is it obvious to everyone what the proxy/UA/middlebox should return when 
presented with a header/body larger than $SOME_VALUE?

Thanks,

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Mar 2008 11:58:11 -0400

Spencer Dawkins wrote:
> My understanding is that Paul is saying that we should not have 
> normative text that says something like "MUST NOT send headers/bodies 
> larger than $SOME_VALUE". I would agree with that.
> 

Well, 513 "Message Too Large" seems pretty clear.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Mar 2008 15:55:18 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
>
> Spencer Dawkins wrote:

Yeah, I don't think that's an issue.  The issue is more that the designers of those UA's/servers didn't take size into account, and thus always try the bigger size, and don't have an alternative mechanism when they get the 513. (and they don't remember the size restriction for other requests, so they keep doing it again and again and again...until they get blacklisted or throttled)

-hadriel

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 17 Mar 2008 15:05:42 -0500

So best practices guidance seems appropriate here...

Thanks,

Spencer

----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>; "Spencer Dawkins" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 17, 2008 2:55 PM
Subject: RE: [Sip] Comment/question on draft-ietf-sip-body-handling-01.txt

> Well, 513 "Message Too Large" seems pretty clear.

Yeah, I don't think that's an issue.  The issue is more that the designers 
of those UA's/servers didn't take size into account, and thus always try the 
bigger size, and don't have an alternative mechanism when they get the 513. 
(and they don't remember the size restriction for other requests, so they 
keep doing it again and again and again...until they get blacklisted or 
throttled)

-hadriel

---

From: [email-masked]
Date: Mon, 17 Mar 2008 15:22:25 -0500

From: Hadriel Kaplan <[email-masked]>

   So my question is, is it appropriate for a draft such as
   draft-ietf-sip-body-handling-01.txt to potentially define a
   maximum, or at least guidance about it?

The concept is good.  The problem is that draft-ietf-sip-body-handling
is about an entirely different subject, and so isn't an appropriate
place to put the guidance.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Mar 2008 20:21:34 -0400

I could be convinced that there should be some normative specification 
of the *minimum* message size that all sip clients and servers MUST be 
prepared to support. And perhaps it need not be the same for all kinds 
of nodes. It seems more important that middleboxes (whether proxies, 
SBCs, or whatever) not impose undue restrictions on the UAC and UAS.

But I don't think this is the right draft for it.\

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 18 Mar 2008 13:54:22 -0400

> I could be convinced that there should be some normative 
> specification of the *minimum* message size that all sip 
> clients and servers MUST be prepared to support.

RFC 3261 section 18.1.1 currently provides a normative minimum:
"However, implementations MUST be able to handle messages up to the
maximum datagram packet size.  For UDP, this size is 65,535 bytes,
including IP and UDP headers."

Are devices actually exceeding the minimum required by RFC 3261?  Or are
vendors interpreting "handle" as though it is valid to return failure
responses because of size even though less than the normative minimum to
handle?
_______________________________________________
Sip mailing list  https://www.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: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Mar 2008 14:10:00 -0400

> From: Brett Tate [mailto:[email-masked]]
> Sent: Tuesday, March 18, 2008 1:54 PM
> To: Paul Kyzivat; Hadriel Kaplan
> Cc: [email-masked]
> Are devices actually exceeding the minimum required by RFC 3261?

Yes.  Some folks think >1MB is ok.  I think they're nuts. :)

> Or are

Yes.  That section of 3261 is about messages - it says nothing about bodies.  Some devices reject requests with bodies that exceed a length, where that length is less than the full 64k for the whole message.  For example, one of my companies' products will reject a SIP message with an overall body bigger than 32KB by default.  It's configurable, but I think we're compliant to reject such by default.

-hadriel

---

From: [email-masked]
Date: Tue, 18 Mar 2008 14:32:28 -0500

> including IP and UDP headers."

   Yes.  That section of 3261 is about messages - it says nothing
   about bodies.  Some devices reject requests with bodies that exceed
   a length, where that length is less than the full 64k for the whole
   message.  For example, one of my companies' products will reject a
   SIP message with an overall body bigger than 32KB by default.  It's
   configurable, but I think we're compliant to reject such by
   default.

That seems a strange restriction to me -- though it accepts some
messages of 64k length, they must include 32kb of headers in order to
do so.  32kb of headers is even scarier than a 1Mb of body...

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Mar 2008 15:47:20 -0400

> Yes.  That section of 3261 is about messages - it says nothing about bodies.  Some devices reject requests with bodies that exceed a length, where that length is less than the full 64k for the whol…

Well, a message includes the body. At least in the case of a proxy I 
think it would be unreasonable to claim that you support a message that 
large yet reject the message because the body is too large.

Aside from an overall limit on message size, IMO a node ought not reject 
a message because some body part it doesn't process is "too large" for 
it. If it has reason to process the body part then perhaps it may have 
cause to reject a part that is too large.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Mar 2008 15:56:36 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, March 18, 2008 3:32 PM
> To: [email-masked]

Not if you look at IMS messages. ;)
Yeah, I don't know why it's 32KB by default, but it is.  Probably some random number generator.  Or a trade-off between "protect weak boxes" and "make-it-workie".  Regardless, without a BCP there was nothing to go by. (not that I'm saying a BCP would make us change behavior, but we try to be good)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Mar 2008 16:10:53 -0400

> large yet reject the message because the body is too large.

Which is why you're not in marketing. ;)

> cause to reject a part that is too large.

Even a proxy may need to really.  Imagine an outbound proxy handling numerous endpoints to the registrar, with one TCP connection to the registrar - if it passes any body size up to the registrar willy-nilly, any endpoint's random 10MB body will impact message forwarding for all others due to HOL. (heck, given the horsepower of some nodes, a 64KB body could too)  Then there's also the reality of TCP not being exactly ubiquitous, to put it mildly, and the odds of a >64KB message making it not being too high.

-hadriel

---

From: [email-masked]
Date: Tue, 18 Mar 2008 15:29:42 -0500

SIP's evil twin...

   Yeah, I don't know why it's 32KB by default, but it is.  Probably
   some random number generator.  Or a trade-off between "protect weak
   boxes" and "make-it-workie".  Regardless, without a BCP there was
   nothing to go by. (not that I'm saying a BCP would make us change
   behavior, but we try to be good)

I'm not particularly worried about your boxes -- I'm sure they're
configurable to match any policy we decide is BCP.

BTW, do you have any comments about the History-Info header?  I'd
think that topology-hiding would cause you to do interesting
processing of History-Info.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Mar 2008 17:03:04 -0400

> processing of History-Info.

It's an ugly one.  Topology-hiding usually makes us strip them, or all but one and change its host if it's E.164 format.  But I don't see as much Hist-info used as Diversion, although that could easily be just because I only get involved when we need to translate between them (which is no fun).  I think Jonathan's approach is architecturally cleaner, as usual, but Christer's is more likely to succeed. :(

-hadriel

---

From: Bob Penfield <[email-masked]>
Date: Tue, 18 Mar 2008 17:32:41 -0400

What about this from RFC 3261:

21.4.11 413 Request Entity Too Large

   The server is refusing to process a request because the request
   entity-body is larger than the server is willing or able to process.
   The server MAY close the connection to prevent the client from
   continuing the request.

   If the condition is temporary, the server SHOULD include a Retry-
   After header field to indicate that it is temporary and after what
   time the client MAY try again.

cheers,
(-:bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, March 18, 2008 3:47 PM
To: Hadriel Kaplan
Cc: [email-masked]; Brett Tate
Subject: Re: [Sip] Comment/question on draft-ietf-sip-body-handling-01.txt

        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Mar 2008 17:52:34 -0400

> Even a proxy may need to really.  Imagine an outbound proxy handling numerous endpoints to the registrar, with one TCP connection to the registrar - if it passes any body size up to the registrar w…

Note that I said "Aside from an overall limit on message size". I can 
see imposing some limit on message size. But if the message doesn't 
exceed that, why would a proxy reject the request because the body was 
too large?

I can see rejecting for a body too large if the proxy needed to process 
that body and it was too big for the proxy to process. But if the body 
is something that is not the proxies business then it has no business 
being fussy about it. Its a distinction between unable and unwilling.

Of course it may have a *policy* about it - that is different. Having a 
policy about the size of a body part is roughly equivalent to having a 
need to process that part.

This of course starts to get ugly with multipart. (E.g. The proxy wants 
to verify the SDP but runs into the 1mb jpg picture of the caller.) 
Depending on how you implement, you may need a lot of storage just to 
deal with the parts you don't care about on the way to finding the 
one(s) you do care about. If you are careful you can do it without a lot 
of storage beyond buffering the message, but I don't know how clever we 
should mandate that people be.

	Paul