Subject: [Gen-art] Re: gen-art review of draft-jennings-sip-voicemail-uri-05.txt

From: Scott W Brim <[email-masked]>
Date: Tue, 03 Jan 2006 18:47:43 -0500

It all looks great to me.  One very very optional nit:

> I'm proposing changing the first para in section 4 from
> 
>    This specification requires the proxy that is requesting the service
>    to understand what are valid targets on the UM system.  For practical
>    purposes this means that the approach is unlikely to work in many
>    cases in which the proxy is not configured with information about the
>    UM system or is not in the same administrative domain.
> 
> To 
> 
>    This specification requires the proxy that is requesting the service
>    to understand whether the UM system it is targeting supports
>    the syntax defined in this specification. Today, this
>    information is provided to the proxy by configuration. For practical
>    purposes this means that the approach is unlikely to work in many
>    cases in which the proxy is not configured with information about the
>    UM system or the UM is not in the same administrative domain.

You can delete the "many" in "in many cases".

See you ... Scott

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 03 Jan 2006 14:12:08 -0800

Hi All, 

Scott and I had a good call and I think we cleared up all the points. I
tried to put my notes from the call and proposed changes to the text inline
the email below. Many thanks to Scott for the careful read.

Allison - I suspect that all of these could be done in Auth 48 or I could
easily put out a new revision of the draft. Which would you like me to?

A copy of the draft with the proposed changes and update of the RFC 4240
reference can be found at:

http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-voicemai
l-uri.txt (there is a .html version too)

I have not submitted this but could trivially submit it if you would like me
too. 

Cullen

On 12/30/05 6:05 AM, "Scott W Brim" <[email-masked]> wrote:

> (for more on gen-art see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html)
> 
> Hi folks.  This is all very cool stuff but I have a few questions.
> Please pardon my lack of SIP knowledge.
> 
> First, Section 4 says there is an assumption that the sender knows
> what target syntax is valid on the receiving system.  Target syntax is
> apparently known with certainty when it is provided by the intended
> recipient e.g. in a "Moved" message.  Other than that, target syntax
> is a local matter, right?

I think I might understand the confusion in the first para of section 4. If
domain A is trying to send something to a voicemail system in domain B,
there are two problems. One is at the semantic level of information: does
domain B even have a voicemail box for Bob? The second is at the syntax
level: how to encode a URL such that domain B knows to route to Bob's
voicemail. 
 
> 
> One of the draft goals is to match expectations of ETSI and TDM
> systems.  Do they already have some syntax defined for targets, at
> least for common situations?  If so, and since the point of the draft
> is to promote common usage, shouldn't they be reproduced or referenced
> here?

They have common things defined on the PSTN side. They are looking for a
mapping of multiple different PSTN things to the SIP. The table in section
2.2 has the mappings from the text names they are using on PSTN side to the
SIP. Other PSTN documents have the encodings for these into the appropriate
PSTN protocol.

> 
> As another possibility, have you considered having a default universal
> target syntax, which would be converted to the local syntax by
> interworking functions?  That would put the problem where it belongs,
> at the receiver (or interworker), not the sender.
> 
> If you don't need this, because target syntax is always known in all
> reasonable deployment cases, then maybe you could redo the first
> paragraph of Section 4?
> 

Scott and I came to the conclusion that was was confusing was that the draft
for this section 4 stuff is that the draft did not explain the following.
The the only way a given network node can know if it can use this URL syntax
to request a service at some given domain, including it's own domain, is by
configuration.

To 

> Next ... Section 8.1 says: "Any redirection of a call to an attacker's
> mailbox is serious.  It is trivial for an attacker to make its mailbox
> seem very much like the real mailbox and forward the messages to the
> real mailbox so that the fact that the messages have been intercepted
> or even tampered with escapes detection."
> 
> There seems to be a general sense that the caller A must depend on the
> security behavior of the callee B, and that the caller has no way to
> authenticate the party it finally connects to (C).  I don't like
> security dependencies.  I don't know enough about SIP to make a
> specific suggestion, but can't A authenticate C the same way it would
> authenticate B in the first place?

This has been a long running debate in SIP. The essence of it is that A
calls B and ends up get a response from C. Should A use that response from C
or ignore it? This draft does not help not hinder that problem. The history
draft actually might allow A to get enough information to make a more
informed decision about it. This draft does not make this problem better or
worse. 

I'm proposing adding the following sentence on to the end of the last
paragraph in section 8.1.

   Approaches such as the SIPS URL and the History mechanism[5] can help
   protect against these attacks.

> 
> Finally, something smaller.  The cause codes (aka redirecting reasons)
> are referred to as SIP "error" codes in 2.0.  Is this just a slip, or
> are informational codes generally referred to as "error" codes in SIP
> drafts?

Good catch. The SIP ABNF calls them Status-Code, a few places in the draft
they get referred to as error codes and in other places error codes but I
think that "status code" is probably a better name for them. Will change to
status. 

> 
> In case you decide to do another revision, there is a typo: "This was
> only done for formatting and is not a valid SIP messages."
> 
> swb

Ah, the problems of having read something so many times that you see what
you wish it said instead of what it actually says. Will remove the s.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 03 Jan 2006 16:21:07 -0800

> You can delete the "many" in "in many cases".

Done. The updated draft is at previous URL.