Subject: [SIP] New draft on SIP registration

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 06 Oct 2000 11:03:10 -0400

I've written a quick draft on some of the issues related to how to do
SIP registration when "visiting" networks. I would appreciate feedback.
The draft does not propose new SIP extensions, except for a possible
Digest parameter to increase registration security.

The draft is
http://www.ietf.org/internet-drafts/draft-schulzrinne-sip-register-00.txt
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Simon Barber" <[email-masked]>
Date: Fri, 6 Oct 2000 12:32:14 -0700

HGS>    Networks are identified by their domain name, independent of whether
HGS>    they belong to the same autonomous system, multicast scope or link-
HGS>    layer local area network. The same physical network may share several
HGS>    such domains. For example, while cs.columbia.edu and columbia.edu are
HGS>    part of the same autonomous system and organization, but they are
HGS>    different domains.  [email-masked] would be visiting the
HGS>    columbia.edu domain as soon as he obtains a Columbia, rather than
HGS>    Computer Science, IP address. A user's local domain is defined by the
HGS>    domain name option configured via DHCP. Some domains do not have a
HGS>    DHCP server, such as the addresses administered by virtual SIP
HGS>    domains [TBD:  need better terminology - this refers to domains such
HGS>    as yahoo.com or hotmail.com that offer the equivalent of web-based
HGS>    email, without any association to a physical network.]

Making assumptions about the relationship between network connectivity and domain
names is a very tricky and fraught with problems. It is probably very dangerous to
make any assumptions in this area.

HGS>
HGS>    We define a traveling user or visitor as a SIP end point that is
HGS>    visiting a domain other than the domain indicated in its SIP URI. The
HGS>    outbound proxy and registrar server in the visited network are called
HGS>    the local proxy and local registrar , respectively. That network is
HGS>    referred to as the visited network , while the user's domain is
HGS>    called the home network , which has home proxy and home registrar
HGS>
HGS>    In any network, a SIP end system needs to establish two SIP-related
HGS>    configuration parameters, namely the local registrar and whether
HGS>    there is an outbound proxy. There are many possible ways this
HGS>    information can be configured, but manual configuration is ill-
HGS>    advised. It is RECOMMENDED that the end system obtain this
HGS>    information via the SIP server DHCP option [6]. In this approach,
HGS>    both local registrar and proxy server are assumed to be the same. In

Why should these be the same? All requests go to the local outbound proxy, but it can
know where the registrar is and forward registrations.

HGS>    the absence of DHCP or manual configuration, a SIP end system has to
HGS>    assume that there is no outbound proxy.
HGS>
HGS> 3 Registration in Visited Network
HGS>
HGS>    In the examples, we let [email-masked] visit the network
HGS>    visited.net.
HGS>
HGS>         Home registration only: In this model, the visiting user simply
HGS>              acquires a local IP address in the visited network and
HGS>              sends a registration with a Contact header indicating that
HGS>              address.
HGS>
HGS>
HGS>              REGISTER sip:wonderland.com SIP/2.0
HGS>              To:
HGS>              From:
HGS>              Contact: sip:[email-masked]

Should not the To: and From: addresses be filled in with [email-masked]?
Otherwise the registrar does not know for whom the registration is, or who sent it.
The alice in the contact could easily be 'visitor_login'.

HGS>
HGS>
HGS>
HGS>              It makes no difference here whether the visited network
HGS>              provides SIP services or not. An outbound proxy can be
HGS>              used, but it simply forwards the REGISTER request based on
HGS>              its request URI.
HGS>
HGS>              This approach works only if the visited network does not
HGS>              use a firewall.  It also means that every location update
HGS>              has to go back to the home network. (This is likely to
HGS>              matter only if IP address changes are frequent.) Also, the
HGS>              proxy in the visited network cannot provide localized
HGS>              services such as emergency calling [7].

Perhaps we need a way for outbound proxies to insert location information headers.

HGS>
HGS>         Outbound proxy intercept: Here, the outbound proxy intercepts
HGS>              the registration request and changes the Contact address to
HGS>              its own address. It has to create a new temporary user
HGS>              identifier that allows it to identify incoming requests for
HGS>              that visiting user. This could be a random identifier or
HGS>              the concatenation of the visitor's address and the proxy's
HGS>              domain, such as [email-masked], where
HGS>              the %40 is the URL-escaped "@" symbol. We call the latter
HGS>              the canonical visitor name.
HGS>
HGS>              This approach has the advantage that it forces incoming
HGS>              requests to use the proxy server.

This solves the firewall problem.

HGS>
HGS>              A rogue user can easily override the registration of the
HGS>              visiting user, although the proxy can provide some security
HGS>              by discarding any registrations where the registration
HGS>              fails in the visiting user's home network. Thus, the
HGS>              visited registrar MUST only act on the registration after a
HGS>              200 (OK) response has been returned by the home registrar.
HGS>              This approach is vulnerable to response spoofing, unless
HGS>              the response is also authenticated by Digest authentication
HGS>              or cryptographic signatures.
HGS>
HGS>              The visiting user could also provide a random basic
HGS>              password when first registering and then be forced to re-
HGS>              use this secret on subsequent registrations. This would
HGS>              limit registration spoofing to those intruders that can
HGS>              snoop the initial registration. A Diffie-Hellman generated
HGS>              key may also be useful, as long as the intruder cannot
HGS>              insert itself into the middle of the registration
HGS>              exchanges. It is probably safest if the local proxy has
HGS>              access to the local AAA mechanism, as that mechanism has
HGS>              verified the visiting user and knows which IP address has
HGS>              been assigned to it.
HGS>
HGS>              As a simple precaution, proxies in visited networks can
HGS>              simply disallow changes of IP addresses for visiting users;
HGS>              however, that then only allows a single instance of a
HGS>              visiting user per visited network.
HGS>
HGS>         User-initiated proxy registration: This is a variation of the
HGS>              previous approach. The visitor recognizes that it is in a
HGS>              foreign network by comparing its URI domain to the domain
HGS>              returned by DHCP in the domain name (Option 15, Section
HGS>              3.17 of [8]) or the SIP server option [6]. If they differ,
HGS>              it uses the address of the SIP server returned by the DHCP
HGS>              SIP server option as its Contact address. This assumes that
HGS>              this address is externally reachable, but even if the
HGS>              domain has it own local DNS and address space, only the
HGS>              name has to be the same, as it will be resolved by DNS SRV
HGS>              records. In most cases, this entry will simply be the
HGS>              domain name.
HGS>
HGS>              The outbound proxy server intercepts the REGISTER request
HGS>              and updates its internal registration.
HGS>
HGS>              User-initiated proxy registration has the advantage that it
HGS>              does not interfere with cryptographically signing
HGS>              registration requests. However, it does require minor
HGS>              adjustments in SIP UAs and additional functionality in SIP
HGS>              registrars.
HGS>
HGS>              To avoid adding numerous configuration options, this only
HGS>              works if all outbound proxy servers can handle such
HGS>              registrations without prior configuration of the user
HGS>              identifier. This method has the same spoofing vulnerability
HGS>              as the previous one.
HGS>
HGS>         Dual registration: In dual registration mode, the visiting UA
HGS>              sends two REGISTER requests, one to the local registrar and
HGS>              another to the home registrar. The registration to the
HGS>              local registrar uses the canonical visitor name to avoid
HGS>              collisions, while the registration at home follows the same
HGS>              rules as the "user-initiated proxy registration" case,
HGS>              except that the proxy server can simply proxy the REGISTER
HGS>              request not addressed to it, rather than having to also
HGS>              interpret it.
HGS>
HGS>              This approach has the advantage that error handling is
HGS>              simplified, as each registration operation can fail
HGS>              individually.
HGS>
HGS>              However, the visitor generally has no credentials to
HGS>              authenticate the local registration, unless the registrar
HGS>              and UA somehow "borrow" credentials from some AAA
HGS>              mechanism, e.g., a CHAP secret. This is not likely to work
HGS>              across network types. (For example, it does not work in the
HGS>              common case where visitors are allowed to plug in laptops
HGS>              in a local area network while visiting a university or
HGS>              research lab.)
HGS>
HGS>              This approach has the disadvantage that it requires two
HGS>              messages between UA and local registrar, which is
HGS>              undesirable particularly for bandwidth-constrained
HGS>              environments. It also requires changes in current SIP UAs.

The current SIP specification suggests dual registration, but the REGISTER to the
local registrar is sent by multicast. What was this originally for?

HGS>
HGS>         Third-party registration: The home registrar registers the
HGS>              visitor in the visited network, supplying its own
HGS>              credentials. The home registrar uses the domain name
HGS>              supplied in the Contact header of the visitor. This can
HGS>              obviously only work if the UA supplies a domain name rather
HGS>              than a numeric IP address.
HGS>
HGS>              This approach has the fundamental architectural flaw that
HGS>              the home registrar is now acting as a UA.
HGS>
HGS>    Note that while the first INVITE in a session uses the outbound
HGS>    proxies, the regular Route mechanism ([1], Section 6.38) takes over
HGS>    for subsequent requests.
HGS>
HGS> 4 Aliases
HGS>
HGS>    Often, SIP UAs have several names, such as a SIP URI derived from the
HGS>    user's email address (e.g., [email-masked]), a name reflecting
HGS>    a telephone extension (e.g., [email-masked]) to ease dialing on
HGS>    IP phones equipped only with a numeric keypad and possibly an E.164
HGS>    address (e.g., [email-masked]). In addition, UAs may
HGS>    not always know their domain name, so that configurations derived
HGS>    from user logins may produce identifiers such as
HGS>    [email-masked].

If we want to provide user mobility the user will have to identify their home domain
correctly - e.g. by logging in as [email-masked]. alice@rathole could be
someone completely different.

HGS>
HGS>    Particularly with telephone extensions, some care needs to be taken,
HGS>    since extensions have traditionally referred to physical lines, not
HGS>    users. Thus, the extension may be associated with a particular device
HGS>    or line.
HGS>
HGS>    Rather than making aliases visible at the protocol level, it may be
HGS>    preferable to have the SIP UA simply register the same Contact for
HGS>    each of these aliases. The registrar then uses the user profile or
HGS>    rewriting rules to associate several different To values with the
HGS>    same internal registration record.
HGS>
HGS>    Similarly, the location server MAY also, without registration,
HGS>    translate the request URI in incoming requests from various alias
HGS>    forms into a canonical user identifier. If the location server can
HGS>    perform this translation, it removes the need for multiple
HGS>    registrations. (TBD: are there cases where this is not the case?)
HGS>
HGS> 5 Home Services while in Visited Network
HGS>
HGS>    For some applications, the user would like to employ services of the
HGS>    home network while generating outbound requests in the visited
HGS>    network.  The visiting UA needs to detect that it is in a foreign
HGS>    network and insert a Route header pointing to its home proxy server.
HGS>
HGS> 6 SIP Naming
HGS>
HGS>    It is RECOMMENDED that a user have a single identifier for email, SIP
HGS>    and as a network access identifier (NAI) [9]. Thus, every SIP URI
HGS>    SHOULD also be usable as an email address. Note that this implies
HGS>    that the algorithm for resolving aliases in proxy servers and SMTP
HGS>    servers SHOULD be the same.
HGS>
HGS> 7 Stale Registrations
HGS>
HGS>    It can occur that a device does not have the opportunity to remove a
HGS>    registration for a particular IP address before being powered down or
HGS>    otherwise being unable to communicate. Registrations will expire
HGS>    automatically, but the expiration time can be sufficiently long that
HGS>    such "orphan" registrations can cause requests to be directed to a
HGS>    network address that has in the mean time been reassigned to another
HGS>    user.
HGS>
HGS>    Recipients of misdirected requests SHOULD respond with 404 (Not
HGS>    Found), which then allows the proxy to remove the registration.
HGS>
HGS>    Also, since registrations are additive, a UA that could not remove a
HGS>    registration at a previous network, will just add the new
HGS>    registration, causing requests to be forked to both the new and the
HGS>    "stale" registration. The UA will obtain all current registrations,
HGS>    but if a single user has multiple devices, it is not easy for the UA
HGS>    to detect stale registrations and remove them.
HGS>
HGS>    One possible solution is to add a unique "tag" parameter to the
HGS>    Contact header of REGISTER requests for those Contact fields where
HGS>    the UA is the authoritative source. The tag value is selected to be
HGS>    independent of the UAs current IP address and only depend on its
HGS>    device identity. Thus, tags are selected such that it never makes
HGS>    sense to have two registrations with the same tag value. The
HGS>    registrar keeps track of the tags associated with a registration and
HGS>    then replaces rather than adds registrations that duplicate existing
HGS>    Contact header tag values.

This is a neat extension.

HGS>
HGS>
HGS>         Using the tag parameter in the To header field was
HGS>         considered, but since a registration may contain many
HGS>         Contact headers, it is not clear whether it should apply to
HGS>         all of them. This UAC-initiated use of the tag parameter
HGS>         also violates the UAS-initiated basic usage in other
HGS>         requests.
HGS>
HGS> 8 Security Considerations
HGS>
HGS>    It is RECOMMENDED that the user name in Basic and Digest is the same
HGS>    as the To header field, rather than a different user name, to
HGS>    simplify the use of global user databases in multi-domain SIP
HGS>    servers.
HGS>
HGS>    Digest authentication does not protect the Contact header against
HGS>    alteration by an adversary. This allows the adversary to redirect
HGS>    calls to another location if it can alter requests. The
HGS>    Authentication-Info header field contains a response digest, but it
HGS>    only protects the response entity body, not header fields. It may be
HGS>    feasible to create a new qop value, "auth-header", that includes all
HGS>    headers of the request except those marked with "c", "a" or "m" in
HGS>    Tables 4 and 5 of [1].  (TBD: this is not particularly easy to
HGS>    implement since it's not clear what to do with unknown headers. Do
HGS>    the kludge that only headers before Authorization are included?)
HGS>
HGS>
HGS>
HGS>         A2 _  Method ":" digest-uri-value ":" H(entity-body) ":" H(e2e-headers)
HGS>
HGS>
HGS> 9 Acknowledgements
HGS>
HGS>    This draft is based on discussions with Jonathan Lennox, Jonathan
HGS>    Rosenberg and Stinson Mathai.
HGS>
HGS> 10 Author's Address
HGS>
HGS>    Henning Schulzrinne
HGS>    Dept. of Computer Science
HGS>    Columbia University
HGS>    1214 Amsterdam Avenue
HGS>    New York, NY 10027
HGS>    USA
HGS>    electronic mail:  [email-masked]
HGS>
HGS> 11 Bibliography
HGS>
HGS>    [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
HGS>    Session initiation protocol," Internet Draft, Internet Engineering
HGS>    Task Force, Aug. 2000.  Work in progress.
HGS>
HGS>    [2] J. Lennox and H. Schulzrinne, "CPL: a language for user control
HGS>    of internet telephony services," Internet Draft, Internet Engineering
HGS>    Task Force, Mar.  1999.  Work in progress.
HGS>
HGS>    [3] J. Lennox, J. Rosenberg, and H. Schulzrinne, "Common gateway
HGS>    interface for SIP," Internet Draft, Internet Engineering Task Force,
HGS>    May 1999.  Work in progress.
HGS>
HGS>    [4] J. Lennox and H. Schulzrinne, "Transporting user control
HGS>    information in SIP REGISTER payloads," Internet Draft, Internet
HGS>    Engineering Task Force, Mar. 1999.  Work in progress.
HGS>
HGS>    [5] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying
HGS>    the location of services (DNS SRV)," Request for Comments 2782,
HGS>
HGS>
HGS>
HGS> Schulzrinne                                                   [Page 8]
HGS>
HGS> Internet Draft                    SIP                    October 5, 2000
HGS>
HGS>
HGS>    Internet Engineering Task Force, Feb. 2000.
HGS>
HGS>    [6] G. Nair and H. Schulzrinne, "DHCP option for SIP servers,"
HGS>    Internet Draft, Internet Engineering Task Force, Apr. 2000.  Work in
HGS>    progress.
HGS>
HGS>    [7] H. Schulzrinne, "Providing emergency call services for sip-based
HGS>    internet telephony," Internet Draft, Internet Engineering Task Force,
HGS>    July 2000.  Work in progress.
HGS>
HGS>    [8] S. Alexander and R. Droms, "DHCP options and BOOTP vendor
HGS>    extensions," Request for Comments 2132, Internet Engineering Task
HGS>    Force, Mar. 1997.
HGS>
HGS>    [9] B. Aboba and M. Beadles, "The network access identifier," Request
HGS>    for Comments 2486, Internet Engineering Task Force, Jan. 1999.
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS>
HGS> Schulzrinne                                                   [Page 9]
HGS>
HGS>
HGS> HGS>

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Henning Schulzrinne
> Sent: Friday, October 06, 2000 8:03 AM
> To: [email-masked]
> Subject: [SIP] New draft on SIP registration
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 06 Oct 2000 19:17:18 -0400

Simon Barber wrote:

> make any assumptions in this area.

Indeed, one of the goals of this draft is to more clearly identify these
assumptions and find out where they break down. We have:

- the domain of the DHCP server, generally equally to a broadcast domain
(LAN), which determines the outbound proxy server;

- the multicast scope, for multicast registrations, also equal to the
LAN in most practical cases (but it gets a little fuzzier);

- the domain name, which may not have any relationship to a broadcast
domain or LAN or multicast scope.

Could you elaborate on where you see the problem in the registration
context?

A visitor uses the local DHCP to find the local domain name and outbound
proxy (if present); it knows, by configuration, its home domain. 

There is one potential problem if the multicast scope does not agree
with the DHCP broadcast scope, but that would be a violation of, at
least, IPv6 "there is no broadcast" principles and likely cause other
difficulties (e.g., with IGMP).

> know where the registrar is and forward registrations.

Good point, although in practice, things are going to get messy if the
proxy and the registrar are not co-located, at least for the cases where
you want to intercept and modify the registration ("outbound proxy
intercept"). The proxy would have to create a copy of the REGISTER, with
the local address, and forward it to the registrar.

> Should not the To: and From: addresses be filled in with [email-masked]?

I don't know what copy you have, but mine has this filled in... I
checked the internet-drafts directory and it's correct there, too.

> Perhaps we need a way for outbound proxies to insert location information headers.

Actually, I believe my statement is not quite true. The outbound proxy
can still provide mapping from, say, INVITE sip:911 to a locally valid
address, even if there's no registration.

> local registrar is sent by multicast. What was this originally for?

This hasn't been updated to reflect DHCP configuration (plus, we
probably don't want to make the main spec rely on DHCP). I'd be curious
if existing implementations do send two REGISTER when visiting.

> In addition, UAs may

Yes, to allow remote registration, that's pretty much unavoidable.
However, the home registrar knows that alice@wonderland and
[email-masked] are really the same person and can thus act
accordingly. For the visited network, it treats these as two different
identifiers. In any event, end systems should know their identity, but
there are vice-presidential candidates that don't know who they are...