Subject: [Speermint] Arch draft review follow-ups

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 19 Sep 2006 21:53:38 -0400

There was a rather lively conversation that occurred after lunch on the
final day of the interim meeting that I believe should be extended to
the mailing list.  I asked the group if an Enterprise should be
considered a VSP within the context of SPEERMINT.  I believe that though
there must be certain considerations, generally speaking an Enterprise
is, for all intents and purposes, a VSP.  

The second issue at hand that needs further discussion and possible
incorporation was the "interface context" of SPEERMINT.  Is SPEERMINT
about NNIs, UNIs or both?  I acknowledge, as Richard Stastny pointed
out, there is no difference to SIP, but Martin brought up the point
about Enterprises being treated as a "customer" and therefore an assumed
UNI relationship. 

I ask these questions to determine if there is a place for both
Enterprises and "interface contexts" (I can think of a better term at
the moment) within the Arch ID.

Thoughts?

Adam Uzelac
Principal Network Architect/Sr. Manager Converged Architecture
Global Crossing
585-255-8916 

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 20 Sep 2006 12:58:05 +0200

> is, for all intents and purposes, a VSP.  

So do I.

> about Enterprises being treated as a "customer" and therefore an assumed

Yes, if an enterprise talks to a "carrier" (whatever that may be), this
is probably a customer/provider relationship and thus similar to UNI.

But what about enterprises talking to enterprises? If we follow the
naming scheme, wouldn't that be an UUI?

> the moment) within the Arch ID.

I'd say that the federations enterprises will form to talk amongst
themselves will likely use different policies (on *all* levels) than
federations built by the ATTs/Sprints/GCs/... of this world.

(My guess is that they will be much more willing to do dynamic peering
(probably TLS-based), no settlement at all, very basic call functions,
no ressource reservations, and none of the higher-level PSTN functions
like caller-id suppression. Look at Microsoft's Live Communication
Server [or whatever it is called now] for some ideas.)

/ol (just arrived back home. Thanks again to Jason for hosting this meeting!)
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 20 Sep 2006 15:33:11 +0200

Just for Information and to answer some question, I attach here the requirements
from ECMA brought forward to TISPAN last week:
 
Richard

Ecma/TC32-TG17/2006/036

Contribution to TISPAN WG1 and WG2

TISPAN#11bis. Sophia Antipolis, 11-15 September 2006

ETSI TISPAN contribution 11bTD079

Title: Enterprise requirements on NGN

Source: Ecma TC32-TG17 members

Contact: John Elwell ([email-masked])

Date: 2006-08-21

1      Introduction

During joint sessions between TISPAN working groups and Ecma TC32-TG17 in June, especially the session involving TISPAN WG1 and WG7, it was found that the "requirements" on NGNs in ECMA TR/91 (ETSI TR 102 478) were in some cases not pure requirements but were based on certain assumptions about the nature of the interface between an enterprise network (NGCN) and an NGN. This contribution, tries to identify some of the real requirements. Additional requirements might arise following further study of topics such as wireless interfaces, nomadic business users and services and applications provided within the NGCN.

2      Assumptions

This contribution assumes an interface between an NGN and an enterprise network or Next Generation Corporate Network (NGCN). This interface has to support, as a minimum, scenarios 4 and 5 from ECMA TR/91 (ETSI TR 102 478), and probably scenario 2 as well. This includes communications between:

·         a user on an NGCN and a user (e.g., residential or small business) on an NGN;

·         a user on an NGCN and a user on PSTN/ISDN accessed via a gateway in the NGN;

·         a user on an NGCN and a user on another carrier network accessed via an NGN;

·         a user on an NGCN and a user on another enterprise network accessed via an NGN;

·         a user on an NGCN and am NGN-hosted user from the same or a different enterprise.

In the last case the other enterprise network could also be another part of the same enterprise.

The NGN and NGCN provide VoIP and other communication services and applications. Transport between the two networks is over public and/or private IP networks using IPv4 and/or IPv6. NATs and/or firewalls will probably exist on both the NGCN and NGN side of the boundary.

The signalling protocol is SIP. The requirements in this document will influence the way SIP is used at this interface and may lead to extensions to SIP.

3      Requirements

3.1     General

REQ1.  An NGN shall offer a standard SIP signalling interface to an NGCN based on standards track RFCs from the IETF.

REQ2.  An NGN shall not make any assumptions about the nature of SIP entities within an NGCN.

NOTE. In addition to pure proxies in accordance with RFC 3261, there can be various designs of B2BUA.

REQ3.  Except when providing a gateway to PSTN/ISDN or an application layer service, an NGN shall be transparent to signalling that is of an end-to-end nature and shall be tolerant of any that is not supported.

NOTE. In particular this applies, to SDP, where the NGN is required to be tolerant of any extensions. Also it applies to event packages that might not be supported by an NGN when a SUBSCRIBE request is targeted at an end user or enterprise rather than at an application within the NGN.

REQ4.  An NGN shall be able to discriminate between normal traffic and intra-enterprise traffic when applying measures for complying with regulations, thus keeping enterprise network internal communications free from any unwanted intervention.

NOTE. For example, regulations might not require legal interception of intra-enterprise traffic or distinct procedures for emergency calling.

3.2     Media

REQ5.  An NGN shall allow the use of any IP-based media during a communication session subject to the availability of resources and contractual arrangements. 

REQ6.  Except where authorised through explicit agreement with the NGCN (by signalling or contract) or to meet formal legal requirements, an NGN shall not intervene in media transport above the transport layer.

NOTE. Examples of reasons for agreed intervention are transcoding, translation and bridging. The default of no intervention is to avoid undue performance impairment (particularly for real-time telemetry data, bidirectional audio and video) and to safeguard perceived confidentiality of the media.

REQ7.  An NGN shall allow the transport of media by via the same NGN as signalling and the transport of media via other routes.

NOTE. For example, for communication between two enterprise networks, an NGN may be involved in signalling (to assist in routing from the first enterprise to the second enterprise), but media traffic could flow directly through any IP network such as the public Internet.

3.3     NAT and firewall traversal

REQ8.  An NGN shall allow an NGCN to use methods such as STUN and ICE as a means of NAT traversal, thereby eliminating any need for an NGN to inspect or modify transported IP addresses and ports in SIP/SDP messages.

NOTE. This does not preclude an NGN offering other NAT traversal solutions that might involve inspecting or modifying IP addresses and ports in SIP/SDP messages. However, the deployment of such techniques should be subject to agreement with the NGCN operator, since such behaviour can be detrimental (e.g., by preventing end-to-end encryption or integrity protection of SDP information), 

3.4     User identities

REQ9.  An NGN shall support identification of users and services by means of Addresses of Records in the form of SIP or SIPS URIs and optionally by means of telephone URIs.

REQ10.      AN NGN shall allow an NGCN to use its own domain name for its user identities.

REQ11.      An NGN shall allow an NGCN freedom to choose its own user parts for SIP/SIPS URIs within its own domain.

NOTE. For example, an NGCN might choose to use alphabetic characters.

NOTE. An NGCN might use aliases internally. For example, aliases that reveal a user's real name might be used internally but when communicating with or via an NGN, numeric or random user-parts might be used for anonymity. Also an NGCN might use only group URIs externally, rather than using an individual's URI, if return or repeat calls to that individual are not desired. Such behaviour should not be visible to the NGN.

REQ12.      An NGN shall allow an NGCN to assign new identities within its domain without prior arrangement with the NGN.

REQ13.      An NGN shall support NGCN user identities that map to E.164 numbers.

REQ14.      An NGN shall allow an NGCN to change mappings between identities within its domain and E.164 numbers without prior arrangement with the NGN.

NOTE. This implies that for a call from PSTN/ISDN to the NGCN the NGN must be able to determine that the called E.164 number is within the NGCN domain and hence route the call to the NGCN indicating as destination either called the E.164 number or a discovered NGCN identity obtained from information published by the NGCN (e.g., DNS).

REQ15.      An NGN shall support NGCN user identities that do not map to E.164 numbers.

NOTE. Although NGCN user identities that do not map to E.164 numbers will not be directly reachable from PSTN/ISDN, they should be reachable from other NGCN or NGN users.

REQ16.      An NGN shall not require to know about individual device (SIP UAs) registered for a given identity (Address of Record) within an NGCN domain.

NOTE. This implies the SIP registrar and location server functionality be located within the NGN and that REGISTER requests from UAs be handled within the NGCN and not forwarded to the NGN.

3.5     User identity delivery

REQ17.      An NGN shall be able to deliver calling and connected user identities to the NGCN, subject to availability and the absence of privacy or regulatory requirements that forbid such delivery. 

REQ18.      When delivering a calling or connected user identity to the NGCN, an NGN shall deliver an identity suitable for making a return or repeat call to the user concerned, subject to the conditions in REQ17.

NOTE. This means that if the user is in another enterprise network, the NGN is required to deliver the identity supplied by that enterprise network, and not some default identity for the enterprise that would result in return or repeat calls going to an attendant, for example.

REQ19.      When delivering a calling or connected user identity to an NGCN, an NGN shall provide appropriate evidence of the authenticity of that identity.

NOTE. In SIP terms, this means either use of the P-Asserted-Identity header field, with reliance on transitive trust right back to the originating domain, or use of the From header field coupled with a signature in the Identity header field supplied by the originating domain.

REQ20.      When receiving a calling or connected user identity from an NGCN, an NGN shall be able to accept evidence of the authenticity of that identity.

NOTE. In SIP terms, this means either use of the P-Asserted-Identity header field or use of the From header field coupled with a signature in the Identity header field supplied by the NGCN domain.

REQ21.      An NGN shall be able to apply privacy to calling and connected user identities within an NGCN on a permanent or call-by-call basis, such that identities are not disclosed to other parties.

NOTE. This means that an NGN must not deliver to other parties in such circumstances either an identity supplied by the NGCN (and marked as private) or a default identity that the NGN assigns to the NGCN.

3.6     User agent identities

REQ22.      An NGN shall deliver globally routable UA identities (contact URIs) to the NGCN.

NOTE. Although within the context of a SIP dialog, contact URIs that are not globally routable can be used if the record route mechanism is used to assist routing, globally routable contact URIs are needed for routing requests outside the context of an existing dialog to a particular UA.

3.7     Signalling security

REQ23.      An NGN shall provide encryption and integrity protection of SIP messages on the NGCN-NGN interface.

NOTE. TLS would be a solution for this.

NOTE. No requirement is seen for the ability not to use security on the NGCN-NGN interface, i.e., a solution where security is always provided would be acceptable and perhaps desirable.

REQ24.      An NGN shall provide an NGCN with means of authenticating the first hop SIP entity within the NGN.

NOTE. For example, the use of an appropriate certificate by the NGN for signing messages during TLS handshake would fulfil this requirement.

NOTE. An NGN may also require an NGCN to deliver a certificate for the purpose of authenticating the NGCN. This might be useful in the context of authorization and billing for NGN services.

REQ25.      An NGN shall allow the encryption and integrity checking of data in SIP messages for end-to-end delivery when required by the NGCN without requiring access to the key, except where regulatory requirements dictate otherwise.

NOTE. Examples are geographic location information and parameters for media security. Where certain parts of such data need to accessed (but not modified) by the NGN, arrangements will need to be made for this to be delivered to the NGN separately (either unencrypted or encrypted for decryption by the NGN). ). For intra-enterprise traffic routed through an NGN, regulatory issues will not apply.

REQ26.      An NGN shall be able to provide security (encryption, authentication and integrity checking) of signalling on each signalling hop between communication partners on request and each NGN shall be able to provide to the NGCN evidence that this is provided.

NOTE. This can in principle be achieved using the SIPS URI scheme, although some flaws with this are currently being investigated in the IETF.

3.8     Media security

REQ27.      An NGN shall permit media to be secured (encrypted, authenticated and integrity protected) end-to-end or end to PSTN/ISDN gateway, except where authorised intervention in media occurs (see REQ6).

REQ28.      An NGN shall permit key management for the purpose of media security to take place between the end devices (or end device to PSTN/ISDN gateway), with cryptographic evidence that this is so.

NOTE. For example, if an NGCN user receives from the NGN authenticated identity of the remote user, the user also needs evidence that key exchange is carried out with that user's device, and not with some network intermediary.

________________________________

Von: Otmar Lendl [mailto:[email-masked]]
Gesendet: Mi 20.09.2006 12:58
An: [email-masked]
Betreff: Re: [Speermint] Arch draft review follow-ups

So do I.