At 02:42 PM 7/11/2007, DRAGE, Keith \(Keith\) wrote:
You wrote:
> In general, I think we have learned that we should help
> people with debugging distributed systems with distributed
> responsibility, as otherwise they'll either struggle or
> invent private mechanisms to include this information. (See
> SER for the the latter.)
If we are not careful here we end up back in the issue of responses
being significantly larger than the request sent on a particular hop,
and therefore the old problem of what happens on UDP when this occurs.
one crazy (or stupid?) idea is
- now that there is a more robust Geolocation-Error header in
responses (verses a Reason or Warning header), a *(SEMI CAType) could
be added to it to allow a Location Recipient to include each CAType
it had a problem with or wasn't there that was considered necessary
to use the location in the first place. This idea doesn't include
the element values, just the elements - which saves bytes, and
doesn't reveal the element values either. It also doesn't include a
message body in the response.
I think this is more information than is presently there, making for
better decisions by location inserters or for troubleshooting. The
only security risk I see with this is the listing of some of the
CAtypes that were in the original request. Presumably there were
other elements in the request, so little (if anything) can be
extracted from this knowledge if intercepted.
Regards
Keith
> -----Original Message-----
> From: Henning Schulzrinne [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 07, 2007 1:06 PM
> To: Paul Kyzivat
> Cc: [email protected]; James M. Polk
> Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header
>
>
> On Jul 6, 2007, at 11:24 PM, Paul Kyzivat wrote:
>
> > Is it really reasonable to expect a proxy that inserts a
> location to
> > remember what location it inserted, in enough detail to
> diagnose why
> > it might have been messed up? I presume it would have to
> reconstruct
> > what the location would have been based in information in the
> > response. It may not be possible to reconstruct the exact
> same value,
> > because the UAC may have moved in the meantime. I guess the
> inserted
> > location would have to be by reference, but the URL of the
> reference
> > may itself not be easily reconstructed, and multiple
> queries of it may
> > not return the same result.
> >
> > IMO it would be much clearer to include the location itself in the
> > response. And if the location had been passed by reference,
> it might
> > be better to pass it by value in the response, so that there is no
> > possibility of the value changing.
> >
>
> I tend to agree that this would be better. The
> reference-to-value translation may not always be feasible: If
> a proxy inserts a location reference and a downstream proxy
> finds a problem, it can't insert a value (except by the data
> URL mechanism I have been mentioning...).
>
>
> > OTOH that might result in divulging the location to nodes
> upstream of
> > the one that included it. If it was passed by reference
> then the node
> > that had inserted it could remove the reference in the
> response. But
> > if it is passed back by value that isn't allowed.
> >
> > The alternative is that the proxy will have to retain the location
> > until the completion of the transaction. Maybe that's ok,
> but if its
> > only to diagnose an occasional glitch I get it doesn't get done.
>
> My assumption was that most locations will be inserted by the
> UAC rather than a proxy. In those cases, retaining the
> information is probably not a big deal, since the UAC will
> generally only have one.
>
> In summary, I think returning as much information about the
> erroneous location information as possible seems best, i.e.,
> both the location information and the party that inserted it.
> This avoids the "who the heck put that bogus location
> information in there?" problem.
>
> In general, I think we have learned that we should help
> people with debugging distributed systems with distributed
> responsibility, as otherwise they'll either struggle or
> invent private mechanisms to include this information. (See
> SER for the the latter.)
>
>
> >
> > Paul
> >
>
>
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> [EMAIL PROTECTED] for questions on current sip
> Use [EMAIL PROTECTED] for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
