Tom -
Could you please include me in the conference call?
Thanks ---- Bob Bell
-----Original Message-----
From: Tom-PT Taylor [mailto:Tom-PT.Taylor.taylor@NT.COM]
Sent: Thursday, October 15, 1998 10:54 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Contact Info requested
What's the contact info for Mark Reid? He was supposed to set up a kick-off
conference call for the Gateway Decomposition study. I wanted to check on
status and set up the call myself if he is too busy.
Tom Taylor
E-mail: …
[View More]taylor(a)nortel.com (internally Tom-PT Taylor)
Tel.: +1 613 765 4167 (internally 395-4167)
FAX: +1 613 763 7236 (internally 393-7236)
------------------------------------------------------------------
This message was spam-checked by an evaluation copy of MailShield.
See http://www.mailshield.com for more information.
[View Less]
I would not say that SGCP and IPDC are at all replacing H.323. These
protocols are used between a Media Gateway Controller (MC) and a Media
Gateway (MG), as device control protocols. An MG is used for telephony to
packet conversion, from, for example, PSTN to IP. Interworking with H.323
would occur in the MC and/or the MG.
>From what I understand, there is a new work item for developing a device
control protocol within SG16. I hope that SGCP and IPDC, and the imminent
merging of the two, …
[View More]will be considered as a basis for this protocol. There
will be a device control WG set up shortly in the IETF, as well as a mailing
list for this subject. I will forward this and the proposed charter for the
WG to this mailing list as soon as I receive it.
Nancy
Friday, October 8/98, Dave Walker wrote:
> Dear Mme Lapierre,
>
> I find it a little confusing that your email says that standards
> makers will present what the signalling of VoIP will look like,
> and that your agenda refers to the session as an H.323/IP workshop,
> yet none of the scheduled talks seem to talk about H.323. Rather
> there seems to be a focus on the gateway control protocols (SGCP
> and IPDC) which as you know, are being pushed by some parties as
> replacements for H.323. Can you clear up my confusion?
>
> Regards,
>
> Dave Walker
> Mitel Corporation
> Ontario, CANADA
>
> Martine.Lapierre(a)alcatel.fr wrote:
> >
> > Good evening,
> >
> > please find attached an invitation to a workshop on VoIP where key
> > VoIP experts will be present.
> > Standards makers will present what the signalling of VoIP will look
> > like, and its impact on the network architecture.
> > IP / VoIP manufacturers will be there.
> > Operators will be discussing how and when they see VoIP in their
> > networks.
> > I will be happy to chair this session.
> >
> > The workshop is sponsored by the TINA consortium, so that the entry
> is
> > free.
> > Nevertheless, we need to know the number of persons who will attend
> to
> > determine the room size, so be kind enough to register if you or a
> > representant of your company are coming.
> >
> > Martine Lapierre
>
> > 3 times a year, all telecom operators, telecom manufacturers and IT/IP
> manufacturers
> > use to meet in the TINA Consortium Technical Forum for a week of
> worgroups exchanges,
> > Request For Pproposals examinations, including an open workshop.
> >
> > EURESCOM and the TINA Consortium are pleased to invite you to the
> October 98 open
> > workshop on H323/IP, that will focus mainly on 2 issues:
> > - The re-use of the existing vocal services unto a VoIP network
> > - The network architecture and signalling for an IP based vocal and
> data operator.
> >
> > During the afternoon, four presentations and an open discussion will
> take place.
> >
> > AGENDA:
> >
> >
> > Introduction Martine LAPIERRE,TINA-C president
> >
> > Christian HUITEMA, Bellcore : Controling routers with the SGCP
> protocol defined by
> > Bellcore and Cisco; the IETSF group; VoIP network architectures
> >
> > Ike ELLIOT, Level3 and Pete O'CONNELL, Alcatel: Controling VoIP networks
> with IPDC;
> > associated network architectures
> >
> > Didier GUY (France Telecom): what could be the future of the telecom
> Switches; can TINA
> > bring something to VOIP?
> >
> > William NAVARRO (ETSI/UMTS/TFO Leader, Nortel): introducing VoIP in
> mobile networks:
> > the Tandem Free Operations signalling, and the IP based UMTS Phase 2
> possible network
> > architecture
> >
> > Question and Answer Session.
> >
>
--------------------------------------------------------------------------
Nancy Greene (internally Nancy-M Greene)
Internet & Service Provider Networks, Nortel
NOTE NEW #'s: T:514-271-7221 (internally ESN853-1077)
E:ngreene@nortel.com
--------------------------------------------------------------------------
Nancy Greene (internally Nancy-M Greene)
Internet & Service Provider Networks, Nortel
NOTE NEW #'s: T:514-271-7221 (internally ESN853-1077)
E:ngreene@nortel.com
--------------------------------------------------------------------------
Nancy Greene (internally Nancy-M Greene)
Internet & Service Provider Networks, Nortel
NOTE NEW #'s: T:514-271-7221 (internally ESN853-1077)
E:ngreene@nortel.com
[View Less]
In the Geneva meeting, it was agreed that the Annex G protocol would be specified in ASN.1, but that the encoding may be one of three possible types (to be decided):
1) templates in BER, with binary wrapper
2) octet strings for templates, binary wrapper
3) octet strings for templates, wrapper in BER
I would agree that H.235 needs to be updated once Annex G has reached more stability. In addition to specifically describing the authentication, confidentiality, integrity, non-repudiation and …
[View More]access control mechanisms, I think that the key exchange mechanisms would be very significant in the inter domain scenario. We could either include support for IKE or could include specific features of IKE into the application layer.
Regarding whether password based or certificate based mechanisms are more appropriate in an inter-domain scenario, I'd say that they each have their place. In a peering relationship between autonomous systems, a password based mecahnism would suffice - this would be fast and efficient and can be delpoyed easily. But, in the longer term and where no peering relationship exists, a certificate based mechanism may be more appropriate.
Issues such as IPSEC or TLS suitability will be clearer depending on when/where UDP/TCP is used within Annex G.
- Senthil
Senthil Sengodan
Nokia Research Center, Boston
----------
From: Euchner Martin
To: Jim Toga; Mailing list for parties associ
Cc: voip; TIPHON; Klasen Wolfgang
Subject: RE: Gk-GK Call signalling - security????
Date: Wednesday, October 14, 1998 10:35AM
I agree that H.235 provides already many useful security functions and
signaling capabilities that could potentially be used also in annex G. Of
course, it has to be described how they could be applied in the new scenario
as H.235 does not know about administrative domains and communication among
them.
Please be aware, that the introduction of this new scenario clearly extends
the H.323v2 scope and especially the scope of H.235. You can see this by
looking at the high and low priority requirements in annex G. For example,
there are requirements saying that border elements can mutually authenticate
as well as a foreign GK can authenticate an entity in a different
administrative domain. I do not quite see how both issues could be addressed
by (present) H.235. The "remote authentication" issues sound challenging; to
me; it is not quite clear what 'element' exactly is meant (is it a GK, an
endpoint,...)?
Another issue is authorization and access control. Present H.235 defines
access (authorization) tokens that are useful between endpoints, GK and GW
within a zone/administrative domain. Possibly, the mechanism could be
extended for annex G purposes.
Therefore, it appears to me that annex G requires at least certain "security
glue" that describes for example how the authentication within a zone,
between administrative domains and authorization fits together.
I see also a requirement for non-repudiation services between border
elements. H.235 presently does not define explicitly any non-repudiation
services. What exactly is the purpose of this non-repudiation? Is it just
limited to the border-to-border element communication using annex G
protocols is it a more general requirement addressing also other H.323
communication carries across reference point A?
Thus, all the listed security requirements seem very important for annex G.
Technically, what is less clear to me is what kind of interrelation exists
between two administrative domains: Can we assume some sort of passwords to
exist between administrative domains such that some sort of
"subscription-like" security mechanisms could be applied? Or is an
administrative domain rather an isolated environment that does not share
certain (long-term) secrets with anybody else? In this case public-key
techniques seem more appropriate.
My impression on the understanding of the annex G definitions is that an
administrative domain very closely resembles a so-called security domain;
i.e. a set of administered elements conforming to a certain security policy.
Thus, there is a certain level of trust within a domain but not always
between domains. A common technology applied today to shield a security
domain is using a firewall with network address translation and proxy.
Border elements are in the position of an edge device on the security domain
perimeter and should offer certain firewall functionality such as protecting
the security domain and hiding zone topology information. A first approach
shown in annex G is the option that a border element releases only very
restricted template information about its zone/domain.
Finally, going back to Jan's statement. From following past annex G
discussion from the far distance so far, my impression is that most of the
discussion has been focussing more on the scope and scenario issues while
the protocol details (such as using RAS and/or something else) was not of
primary concern. Unfortunately, unless it is clear what signaling protocols
are actually used for annex G, it is a bit difficult to progress
substantially on the related security issues.
martin.
-----------------------------------------------------------------------
| Dipl.-Inf. Phone: +49 89 636-46201
| Martin Euchner Fax : +49 89 636-48000
| Siemens AG
| ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de
|
| Otto-Hahn-Ring 6
| 81730 Muenchen
| __________________
| Germany
-----------------------------------------------------------------------
> -----Original Message-----
> From: Jim Toga [SMTP:jim.toga@intel.com]
> Sent: Dienstag, 13. Oktober 1998 19:10
> To: Euchner Martin; Mailing list for parties associated with ITU-T Study
> Group 16; ITU-SG16(a)mailbag.cps.intel.com
> Cc: voip(a)imtc.org; TIPHON(a)list.etsi.fr; Klasen Wolfgang
> Subject: Re: Gk-GK Call signalling - security????
>
> Martin,
>
> I would corroborate Senthil's point. All of the capabilities to utilize
> H.235 functionality (including the use of 'external' mechanisms such as
> TLS or IPSec) are indended to be available to annex G signaling.
>
> Some (ok much...) of the procedural description is not included yet. If
> anyone sees any specific barriers in accomplishing this, please speak up.
>
> jimt.
>
> At 11:50 AM 10/13/98 -0400, Sengodan Senthil NRC/Boston wrote:
> >I believe ITU will in fact provide the needed security features for
> inter-gatekeeper communication. The determined version of Annex G already
> has an authentication field in the zone exchange messages. However,
> providing such fields does not guarantee interoperability unless specific
> security mechanisms are mandated - which the ITU will probably not get
> into. This work - of specifying security profiles for interoperability -
> falls within IMTC VoIP and TIPHON.
> >
> >Regarding Jan's comment, as Gur alluded to, Annex G's immediate focus is
> address resolution. Other features, I believe, will be added after this is
> tackled.
> >
> > - Senthil
> >
> >Senthil Sengodan
> >Nokia Research Center, Boston
> > ----------
> >From: Euchner Martin
> >To: IMTC VoIP reflector; Klasen, Wolfgang; Euchner, Martin
> >Subject: RE: Gk-GK Call signalling - security????
> >Date: Tuesday, October 13, 1998 3:11PM
> >
> >I'm somewhat confused about the statement that Annex G security issues
> are
> >not in the scope of ITU's work but inTiphon/IMTC.
> >>From my impression of the recent ITU-T SG16 meeting in Geneva, the
> demand
> >for better security regarding the inter-GK scenario was very clearly
> >expressed. For obvious reasons, ITU's work on defining enhancements in
> annex
> >G implies to address also the security issues in an appropriate way. The
> >requirements section in annex G lists already several security
> requirements,
> >so this work item is already part of their work. Of course, there is no
> real
> >need to invent new security solutions for annex G in case other standards
> >bodies have some appropriate technology available that could be
> referenced
> >for example.
> >Whatever security solutions will come out, the result could very smoothly
> be
> >described and added to the H.235 security recommendation. Note, that
> current
> >H.235 provides already (some) security solutions to H.225.0; thus, annex
> G
> >security features seem a natural enhancement to this work.
> >
> >martin.
> >
> > -----------------------------------------------------------------------
> >| Dipl.-Inf. Phone: +49 89 636-46201
> >| Martin Euchner Fax : +49 89 636-48000
> >| Siemens AG
> >| ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de
> >|
> >| Otto-Hahn-Ring 6
> >| 81730 Muenchen
> >| __________________
> >| Germany
> > -----------------------------------------------------------------------
> >
> >> -----Original Message-----
> >> From: gur kimchi [SMTP:gur.kimchi@ETSI.FR]
> >> Sent: Dienstag, 13. Oktober 1998 14:21
> >> To: TIPHON(a)LIST.ETSI.FR
> >> Subject: Re: Gk-GK Call signalling - security????
> >>
> >> Hi Jan,
> >>
> >> I attended the Q.13 meeting also - and The scope of Annex G
> >> is very well defined: it is attempting to introduce new
> >> mechanisms where none exist today. We could argue for hours
> >> whether there are inter-gk call-singalling mechanism today, and well,
> >> there
> >> are (H.225) - the main missing point there is security - which the ITU
> >> will not define anyway - but TIPHON (and VoIP).
> >>
> >> e.g. the new mechanisms are Zone information Exchange.
> >>
> >> - gur
> >>
> >> -----Original Message-----
> >> From: Ericsson User [mailto:etxjaeh@AL.ETX.ERICSSON.SE]
> >> Sent: 13 October 1998 13:40
> >> To: TIPHON
> >> Subject: Gk-GK Call signalling
> >>
> >>
> >> Hello All,
> >> I participated in the SG 16 meeting in Geneva in september.
> >>
> >> One thing that suprised me was that the ongoing work with Annex G
> (GK-GK
> >> signalling) did not consider call control, only the RAS signalling.
> >>
> >> When I asked why, they did not understand why any change is required.
> >> After a while they understood that something could be needed, but it
> was
> >> postponed to future releases of H.323.
> >>
> >> Future releases must be version 4 or something (around year 2001 or
> >> later ??).
> >>
> >> The conclusion is then (looking on TIPHON project plan) that H.323
> can't
> >> be used between Gatekeepers in TIPHON compliant system.
> >>
> >> The question is then: What do we use then? ISUP? B-ISUP? SIP? Extended
> >> subset of H.323?
> >>
> >>
> >> /Jan Holm
> >> Ericsson Telecom AB
> >>
> >> -------------------------------------------------------------------
> >> ATTENTION !!! TIPHON list distribution parameters have changed:
> >> ==> if you REPLY to a TIPHON mail your mail will be sent to the
> >> original sender only.
> >> ==> if you use REPLY ALL your mail will be sent to TIPHON and
> >> to the original sender.
> >> -------------------------------------------------------------------
> >>
> >> -------------------------------------------------------------------
> >> ATTENTION !!! TIPHON list distribution parameters have changed:
> >> ==> if you REPLY to a TIPHON mail your mail will be sent to the
> >> original sender only.
> >> ==> if you use REPLY ALL your mail will be sent to TIPHON and
> >> to the original sender.
> >> -------------------------------------------------------------------
> >
>
> *****************************************************
> *** +1-503-264-8816(voice) Intel - Hillsboro, OR.
> ***
> *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int ***
> *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 ***
> *****************************************************
[View Less]
To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16
Cc Mr. P-A. Probst, Chairman of SG16
Mr. G. Helder, Vice-Chairman of SG16
Mr. F. Tosco, Chairman of WP2/16
Mr. F. Bigi, ITU-TSB
Mr. T. Geary, Rapporteur for Q.11/16
De Sakae OKUBO
Rapporteur for Q.12/16 in ITU-T SG16
TAO Waseda Research Center
5th Floor, Nishi-Waseda Bldg.
1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
Tel: +81 3 5286 3830
Fax: +81 …
[View More]3 5287 7287
E-mail: okubo(a)giti.or.jp
Dale SKRAN
Rapporteur for Q.13/16 in ITU-T SG16
Ascend Communications, Inc.
621 Shrewsbury Avenue
Shrewsbury, NJ 07702
USA
Tel: +1 908 450 1635
Fax: +1 908 450 1611
E-mail: Dale.Skran(a)ascend.com
Gary Thom
Rapporteur for Q.14/16 in ITU-T SG16
Delta Information Systems Inc.
Horsham Business Center Bldg. 3
300 Welsh Road, Horsham, PA 19044
Tel: +1 215 657 5270 ex 23
Fax: +1 215 657 5273
E-mail: gthom(a)delta-info.com
------------------------------------------------
Subject: Notice of Q.12-14/16 Rapporteur Meeting
Date: 8 October 1998
------------------------------------------------
Dear SG16 Colleagues,
The subject meeting of ITU-T SG16 experts will be held in Torino,
Italy at the kind invitation of CSELT.
Please note that Q.11/16 will meet concurrently at the same place and
have joint sessions with Q.12-14/16.
1. Date
^^^^^^^
17 (Tuesday) - 20 (Friday) November 1998
starting at 9:00 on the first day
2. Venue
^^^^^^^^
CSELT
Via Reiss Romoli 274
10148 TORINO
Italy
Tel: +39 011 2285521
Fax: +39 011 2285295
3. Topics (tentative)
^^^^^^^^^^^^^^^^^^^^^
1) Review of the relevant group meetings
2) Q.12/16 B-ISDN multimedia systems and terminals
- White contribution for H.222.0 Amend. 6
- H.321 Implementors Guide
- MPEG packetization
- Future AV communication system
3) Q.13/16 Packet switched multimedia systems and terminals
- Issue white papers for H.450.4/5/6/7, H.323 Annexes E/F/G
- Advance the work of H.323 V3/H.225.0 V3
4) Q.14/16 Common protocols, MCUs and protocols for interworking with
H.300-series terminals
- Review Recommendations for decision at next SG16 meeting: H.245V5,
H.341 (H.MediaMib), H.283 (H.RDC)
- Preparation of H.246 Annexes for determination
- Discussion of new H.246 interworking Annexes
- Discussion of new H.341 Annexes
5) Any other Q.12-14/16 related matters
- Interaction with other groups
6) Future work
4. Documents
^^^^^^^^^^^^
/// Registration of the document: by 6 November ///
/// Distribution of the document: by 10 November ///
/// Use the ftp site (or e-mail reflector) for distribution ///
1) When you are going to submit a document, please notify S.
Okubo as soon as possible, by 6 November (Friday) at the latest.
Document number (APC-1nnn) will be allocated. Early indication of
your submission plan is welcome.
Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16)
and Common protocols (Q.14/16) based on coordination with Q.1
("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups.
2) You are advised to include a header as follows:
------------------------------------------------------------------
| |
| ITU Telecommunication Standardization Sector Document APC-{1nnn}|
| Study Group 16 {Version m if relevant}|
| Q.12-14/16 Rapporteur Meeting {Date}|
| Torino, 17-20 November 1998 |
| |
| SOURCE*: { } |
| TITLE : { } |
| PURPOSE: {Proposal, Discussion, Information, Report, etc.} |
| |
| _________________________ |
| |
| |
| |
| *Contact: Name, e-mail |
------------------------------------------------------------------
3) All the contributors are requested to distribute their
documents as early as possible, at least 7 calendar days in advance
of the meeting (by 10 November) by posting them at either of the
following:
- PictureTel ftp site (please advise S. Okubo of your posting)
Site: standard.pictel.com/avc-site
Login name: anonymous
Directory: Incoming
- Q.12-14/16 experts reflector
e-mail address: itu-sg16(a)mailbag.jf.intel.com
Please avoid the use of reflector when your document is
voluminous.
4) Input documents can be retrieved from /9811_Tor directory of
the ftp site.
5) Please bring 60 copies of your document to Torino. Your
cooperation is needed to start the meeting with all the documents at
hand; please note that the copying capacity at the meeting site is
limited.
5. Logistic information
^^^^^^^^^^^^^^^^^^^^^^^
Please see the attached information from the meeting host.
6. Registration
^^^^^^^^^^^^^^^
Please notify the following person (Mr. Tosco's secretary) of your
participation as soon as possible, by 10 November at the latest:
Donatella Bertolotti
Tel: +39 011 2285521
Fax: +39 011 2285295
E_mail: donatella.bertolotti(a)cselt.it
with copy to three Rapporteurs (e-mail: okubo(a)giti.or.jp,
Dale.Skran(a)ascend.com, gthom(a)delta-info.com)
7. Hotel Room Reservation
^^^^^^^^^^^^^^^^^^^^^^^^^
Please directly contact a hotel suggested in Mr. Tosco's message as
attached.
We are looking forward to meeting with you in Torino.
Sincerely yours,
Sakae OKUBO
Dale SKRAN
Gary THOM
-----<Mr. Tosco's message to Rapporteurs dated 29 September 1998>----
Date: Tue, 29 Sep 1998 17:34:49 +0200
From: Tosco Federico <Federico.Tosco(a)CSELT.IT>
Subject: November Expert meeting
To: "'Geary, Tom'" <tom.geary(a)nb.rockwell.com>,
"'Okubo, Sakae'" <okubo(a)giti.or.jp>,
"'Skran, Dale'" <Dale.Skran(a)ascend.com>,
"'Thom, Gary'" <gthom(a)delta-info.com>
Dear all,
First of all I would like to confirm the facilities available for the
November meeting:
- auditorium (170 seats)
- meeting room, 40 places
- meeting room, 15-20 places
For information about CSELT, how to reach it, hotels in Torino, etc.,
I suggest you to visit our homepage: http://www.cselt.it.
In particular on the presentation page click on "Overview", where you
will find:
- "Getting to CSELT", where you find information about how to reach
CSELT
- "A guided tour", where under "Supports" some of the facilities,
including the Auditorium, are presented
Under "Getting to CSELT" you find also a list of hotels, where you can
obtain reduced rates mentioning "CSELT Convention".
Torino airport is connected with the main European cities (Paris,
Amsterdam, Frankfurt, Brussels, Zurich, Madrid,...) and has many
flights to/from Rome every day (see link to Turin Airport under
"Getting to CSELT").If you arrive with an intercontinental flight, I
suggest to avoid the intercontinental airport of Milano (Milan), which
is not far from Torino but has poor connections to Torino. Much better
to arrive to Rome or to another destination in Europe having a flight
connection to Torino.CSELT is very close to the Torino airport (15
minutes by taxi).
...
Best regards
Federico
CSELT
Via Reiss Romoli 274
10148 TORINO
Italy
Tel.: +39 0112285321
Fax: +39 0112285295
E_mail: federico.tosco(a)cselt.it
WARNING! New telephone and fax numbers effective June 19, 1998
[View Less]
I agree that H.235 provides already many useful security functions and
signaling capabilities that could potentially be used also in annex G. Of
course, it has to be described how they could be applied in the new scenario
as H.235 does not know about administrative domains and communication among
them.
Please be aware, that the introduction of this new scenario clearly extends
the H.323v2 scope and especially the scope of H.235. You can see this by
looking at the high and low priority …
[View More]requirements in annex G. For example,
there are requirements saying that border elements can mutually authenticate
as well as a foreign GK can authenticate an entity in a different
administrative domain. I do not quite see how both issues could be addressed
by (present) H.235. The "remote authentication" issues sound challenging; to
me; it is not quite clear what 'element' exactly is meant (is it a GK, an
endpoint,...)?
Another issue is authorization and access control. Present H.235 defines
access (authorization) tokens that are useful between endpoints, GK and GW
within a zone/administrative domain. Possibly, the mechanism could be
extended for annex G purposes.
Therefore, it appears to me that annex G requires at least certain "security
glue" that describes for example how the authentication within a zone,
between administrative domains and authorization fits together.
I see also a requirement for non-repudiation services between border
elements. H.235 presently does not define explicitly any non-repudiation
services. What exactly is the purpose of this non-repudiation? Is it just
limited to the border-to-border element communication using annex G
protocols is it a more general requirement addressing also other H.323
communication carries across reference point A?
Thus, all the listed security requirements seem very important for annex G.
Technically, what is less clear to me is what kind of interrelation exists
between two administrative domains: Can we assume some sort of passwords to
exist between administrative domains such that some sort of
"subscription-like" security mechanisms could be applied? Or is an
administrative domain rather an isolated environment that does not share
certain (long-term) secrets with anybody else? In this case public-key
techniques seem more appropriate.
My impression on the understanding of the annex G definitions is that an
administrative domain very closely resembles a so-called security domain;
i.e. a set of administered elements conforming to a certain security policy.
Thus, there is a certain level of trust within a domain but not always
between domains. A common technology applied today to shield a security
domain is using a firewall with network address translation and proxy.
Border elements are in the position of an edge device on the security domain
perimeter and should offer certain firewall functionality such as protecting
the security domain and hiding zone topology information. A first approach
shown in annex G is the option that a border element releases only very
restricted template information about its zone/domain.
Finally, going back to Jan's statement. From following past annex G
discussion from the far distance so far, my impression is that most of the
discussion has been focussing more on the scope and scenario issues while
the protocol details (such as using RAS and/or something else) was not of
primary concern. Unfortunately, unless it is clear what signaling protocols
are actually used for annex G, it is a bit difficult to progress
substantially on the related security issues.
martin.
-----------------------------------------------------------------------
| Dipl.-Inf. Phone: +49 89 636-46201
| Martin Euchner Fax : +49 89 636-48000
| Siemens AG
| ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de
|
| Otto-Hahn-Ring 6
| 81730 Muenchen
| __________________
| Germany
-----------------------------------------------------------------------
> -----Original Message-----
> From: Jim Toga [SMTP:jim.toga@intel.com]
> Sent: Dienstag, 13. Oktober 1998 19:10
> To: Euchner Martin; Mailing list for parties associated with ITU-T Study
> Group 16; ITU-SG16(a)mailbag.cps.intel.com
> Cc: voip(a)imtc.org; TIPHON(a)list.etsi.fr; Klasen Wolfgang
> Subject: Re: Gk-GK Call signalling - security????
>
> Martin,
>
> I would corroborate Senthil's point. All of the capabilities to utilize
> H.235 functionality (including the use of 'external' mechanisms such as
> TLS or IPSec) are indended to be available to annex G signaling.
>
> Some (ok much...) of the procedural description is not included yet. If
> anyone sees any specific barriers in accomplishing this, please speak up.
>
> jimt.
>
> At 11:50 AM 10/13/98 -0400, Sengodan Senthil NRC/Boston wrote:
> >I believe ITU will in fact provide the needed security features for
> inter-gatekeeper communication. The determined version of Annex G already
> has an authentication field in the zone exchange messages. However,
> providing such fields does not guarantee interoperability unless specific
> security mechanisms are mandated - which the ITU will probably not get
> into. This work - of specifying security profiles for interoperability -
> falls within IMTC VoIP and TIPHON.
> >
> >Regarding Jan's comment, as Gur alluded to, Annex G's immediate focus is
> address resolution. Other features, I believe, will be added after this is
> tackled.
> >
> > - Senthil
> >
> >Senthil Sengodan
> >Nokia Research Center, Boston
> > ----------
> >From: Euchner Martin
> >To: IMTC VoIP reflector; Klasen, Wolfgang; Euchner, Martin
> >Subject: RE: Gk-GK Call signalling - security????
> >Date: Tuesday, October 13, 1998 3:11PM
> >
> >I'm somewhat confused about the statement that Annex G security issues
> are
> >not in the scope of ITU's work but inTiphon/IMTC.
> >>From my impression of the recent ITU-T SG16 meeting in Geneva, the
> demand
> >for better security regarding the inter-GK scenario was very clearly
> >expressed. For obvious reasons, ITU's work on defining enhancements in
> annex
> >G implies to address also the security issues in an appropriate way. The
> >requirements section in annex G lists already several security
> requirements,
> >so this work item is already part of their work. Of course, there is no
> real
> >need to invent new security solutions for annex G in case other standards
> >bodies have some appropriate technology available that could be
> referenced
> >for example.
> >Whatever security solutions will come out, the result could very smoothly
> be
> >described and added to the H.235 security recommendation. Note, that
> current
> >H.235 provides already (some) security solutions to H.225.0; thus, annex
> G
> >security features seem a natural enhancement to this work.
> >
> >martin.
> >
> > -----------------------------------------------------------------------
> >| Dipl.-Inf. Phone: +49 89 636-46201
> >| Martin Euchner Fax : +49 89 636-48000
> >| Siemens AG
> >| ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de
> >|
> >| Otto-Hahn-Ring 6
> >| 81730 Muenchen
> >| __________________
> >| Germany
> > -----------------------------------------------------------------------
> >
> >> -----Original Message-----
> >> From: gur kimchi [SMTP:gur.kimchi@ETSI.FR]
> >> Sent: Dienstag, 13. Oktober 1998 14:21
> >> To: TIPHON(a)LIST.ETSI.FR
> >> Subject: Re: Gk-GK Call signalling - security????
> >>
> >> Hi Jan,
> >>
> >> I attended the Q.13 meeting also - and The scope of Annex G
> >> is very well defined: it is attempting to introduce new
> >> mechanisms where none exist today. We could argue for hours
> >> whether there are inter-gk call-singalling mechanism today, and well,
> >> there
> >> are (H.225) - the main missing point there is security - which the ITU
> >> will not define anyway - but TIPHON (and VoIP).
> >>
> >> e.g. the new mechanisms are Zone information Exchange.
> >>
> >> - gur
> >>
> >> -----Original Message-----
> >> From: Ericsson User [mailto:etxjaeh@AL.ETX.ERICSSON.SE]
> >> Sent: 13 October 1998 13:40
> >> To: TIPHON
> >> Subject: Gk-GK Call signalling
> >>
> >>
> >> Hello All,
> >> I participated in the SG 16 meeting in Geneva in september.
> >>
> >> One thing that suprised me was that the ongoing work with Annex G
> (GK-GK
> >> signalling) did not consider call control, only the RAS signalling.
> >>
> >> When I asked why, they did not understand why any change is required.
> >> After a while they understood that something could be needed, but it
> was
> >> postponed to future releases of H.323.
> >>
> >> Future releases must be version 4 or something (around year 2001 or
> >> later ??).
> >>
> >> The conclusion is then (looking on TIPHON project plan) that H.323
> can't
> >> be used between Gatekeepers in TIPHON compliant system.
> >>
> >> The question is then: What do we use then? ISUP? B-ISUP? SIP? Extended
> >> subset of H.323?
> >>
> >>
> >> /Jan Holm
> >> Ericsson Telecom AB
> >>
> >> -------------------------------------------------------------------
> >> ATTENTION !!! TIPHON list distribution parameters have changed:
> >> ==> if you REPLY to a TIPHON mail your mail will be sent to the
> >> original sender only.
> >> ==> if you use REPLY ALL your mail will be sent to TIPHON and
> >> to the original sender.
> >> -------------------------------------------------------------------
> >>
> >> -------------------------------------------------------------------
> >> ATTENTION !!! TIPHON list distribution parameters have changed:
> >> ==> if you REPLY to a TIPHON mail your mail will be sent to the
> >> original sender only.
> >> ==> if you use REPLY ALL your mail will be sent to TIPHON and
> >> to the original sender.
> >> -------------------------------------------------------------------
> >
>
> *****************************************************
> *** +1-503-264-8816(voice) Intel - Hillsboro, OR.
> ***
> *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int ***
> *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 ***
> *****************************************************
[View Less]
I believe ITU will in fact provide the needed security features for inter-gatekeeper communication. The determined version of Annex G already has an authentication field in the zone exchange messages. However, providing such fields does not guarantee interoperability unless specific security mechanisms are mandated - which the ITU will probably not get into. This work - of specifying security profiles for interoperability - falls within IMTC VoIP and TIPHON.
Regarding Jan's comment, as Gur …
[View More]alluded to, Annex G's immediate focus is address resolution. Other features, I believe, will be added after this is tackled.
- Senthil
Senthil Sengodan
Nokia Research Center, Boston
----------
From: Euchner Martin
To: IMTC VoIP reflector; Klasen, Wolfgang; Euchner, Martin
Subject: RE: Gk-GK Call signalling - security????
Date: Tuesday, October 13, 1998 3:11PM
I'm somewhat confused about the statement that Annex G security issues are
not in the scope of ITU's work but inTiphon/IMTC.
>From my impression of the recent ITU-T SG16 meeting in Geneva, the demand
for better security regarding the inter-GK scenario was very clearly
expressed. For obvious reasons, ITU's work on defining enhancements in annex
G implies to address also the security issues in an appropriate way. The
requirements section in annex G lists already several security requirements,
so this work item is already part of their work. Of course, there is no real
need to invent new security solutions for annex G in case other standards
bodies have some appropriate technology available that could be referenced
for example.
Whatever security solutions will come out, the result could very smoothly be
described and added to the H.235 security recommendation. Note, that current
H.235 provides already (some) security solutions to H.225.0; thus, annex G
security features seem a natural enhancement to this work.
martin.
-----------------------------------------------------------------------
| Dipl.-Inf. Phone: +49 89 636-46201
| Martin Euchner Fax : +49 89 636-48000
| Siemens AG
| ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de
|
| Otto-Hahn-Ring 6
| 81730 Muenchen
| __________________
| Germany
-----------------------------------------------------------------------
> -----Original Message-----
> From: gur kimchi [SMTP:gur.kimchi@ETSI.FR]
> Sent: Dienstag, 13. Oktober 1998 14:21
> To: TIPHON(a)LIST.ETSI.FR
> Subject: Re: Gk-GK Call signalling - security????
>
> Hi Jan,
>
> I attended the Q.13 meeting also - and The scope of Annex G
> is very well defined: it is attempting to introduce new
> mechanisms where none exist today. We could argue for hours
> whether there are inter-gk call-singalling mechanism today, and well,
> there
> are (H.225) - the main missing point there is security - which the ITU
> will not define anyway - but TIPHON (and VoIP).
>
> e.g. the new mechanisms are Zone information Exchange.
>
> - gur
>
> -----Original Message-----
> From: Ericsson User [mailto:etxjaeh@AL.ETX.ERICSSON.SE]
> Sent: 13 October 1998 13:40
> To: TIPHON
> Subject: Gk-GK Call signalling
>
>
> Hello All,
> I participated in the SG 16 meeting in Geneva in september.
>
> One thing that suprised me was that the ongoing work with Annex G (GK-GK
> signalling) did not consider call control, only the RAS signalling.
>
> When I asked why, they did not understand why any change is required.
> After a while they understood that something could be needed, but it was
> postponed to future releases of H.323.
>
> Future releases must be version 4 or something (around year 2001 or
> later ??).
>
> The conclusion is then (looking on TIPHON project plan) that H.323 can't
> be used between Gatekeepers in TIPHON compliant system.
>
> The question is then: What do we use then? ISUP? B-ISUP? SIP? Extended
> subset of H.323?
>
>
> /Jan Holm
> Ericsson Telecom AB
>
> -------------------------------------------------------------------
> ATTENTION !!! TIPHON list distribution parameters have changed:
> ==> if you REPLY to a TIPHON mail your mail will be sent to the
> original sender only.
> ==> if you use REPLY ALL your mail will be sent to TIPHON and
> to the original sender.
> -------------------------------------------------------------------
>
> -------------------------------------------------------------------
> ATTENTION !!! TIPHON list distribution parameters have changed:
> ==> if you REPLY to a TIPHON mail your mail will be sent to the
> original sender only.
> ==> if you use REPLY ALL your mail will be sent to TIPHON and
> to the original sender.
> -------------------------------------------------------------------
[View Less]
Jan,
Being one of the contributors of some of the text.... There was no intent
to limit GK-GK communications to RAS or Call Control. The plan of attack
was to initially solve some specific issues with being able to complete
Inter-zone calls.
The fact that the messages are carried in RAS format was simply a straw-man
proposal. The content and logic was the important starting point.
As is always the case, this work moves forward with contributions. What
specific functions do you want to …
[View More]acomplish? It might help me (and others)
to understand where the specific holes are, in order to figure out what the
next holes are (in the IP context) rather simply saying we need to port
ISUP to GKs.
Best Regards,
jimt.
At 01:39 PM 10/13/98 +0100, Ericsson User wrote:
>Hello All,
>I participated in the SG 16 meeting in Geneva in september.
>
>One thing that suprised me was that the ongoing work with Annex G (GK-GK
>signalling) did not consider call control, only the RAS signalling.
>
>When I asked why, they did not understand why any change is required.
>After a while they understood that something could be needed, but it was
>postponed to future releases of H.323.
>
>Future releases must be version 4 or something (around year 2001 or
>later ??).
>
>The conclusion is then (looking on TIPHON project plan) that H.323 can't
>be used between Gatekeepers in TIPHON compliant system.
>
>The question is then: What do we use then? ISUP? B-ISUP? SIP? Extended
>subset of H.323?
>
>
>/Jan Holm
>Ericsson Telecom AB
>
>-------------------------------------------------------------------
>ATTENTION !!! TIPHON list distribution parameters have changed:
>==> if you REPLY to a TIPHON mail your mail will be sent to the
>original sender only.
>==> if you use REPLY ALL your mail will be sent to TIPHON and
>to the original sender.
>-------------------------------------------------------------------
>
*****************************************************
*** +1-503-264-8816(voice) Intel - Hillsboro, OR.
***
*** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int ***
*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 ***
*****************************************************
[View Less]
Hi,
Can anybody answer the following questions regarding the use of
addresses in H.225.0:
1) Type TransportAddress: What is the purpose of alternative
'ipSourceRoute', is it currently used for anything?
2) Type AliasAddress: What is the purpose of alternative
'transportAddress'? Must this be an address of the underlying network
(usually IP), or can it be a different type (for example, an NSAP
address)?
Reason behind question 2): When interworking with an ATM network which
implements ATM-…
[View More]Forum protocols, the ATM terminal's address may be in
NSAP format. Type AliasAddress in H.225.0 has no 'nsap' alternative, but
type TransportAddress has. Could NSAP addresses now be included in
AliasAddress via alternative 'transportAddress'?
Ernst Horvath
Siemens AG
Email: ernst.horvath(a)siemens.at
[View Less]
Dear Mr. Okubo,
Thank you for having made available the WP2/16 report.
Best regards
Federico Tosco
> ----------
> Da: Sakae OKUBO[SMTP:okubo@GITI.OR.JP]
> Risposta a: Mailing list for parties associated with ITU-T Study Group
> 16
> Inviato: lunedì 5 ottobre 1998 11.08
> A: ITU-SG16(a)mailbag.cps.intel.com
> Oggetto: Mr. Tosco report of WP2/16
>
> Dear Q.12-14/16 experts,
>
> Please be advised that Mr. Tosco's report of WP2/16 of the …
[View More]September SG16
> meeting has been placed at the following:
>
> ftp://standard.pictel.com/avc-site/9809_Gen/Tosco_WP2_report.zip
>
> Best regards,
>
> Sakae OKUBO (Mr.)
> ***********************************************************
> Waseda Research Center
> Telecommunications Advancement Organization of Japan (TAO)
> 5th Floor, Nishi-Waseda Bldg.
> 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
> 169-0051 Japan
> Tel: +81 3 5286 3830
> Fax: +81 3 5287 7287
> e-mail: okubo(a)giti.or.jp
> ***********************************************************
>
[View Less]
Dear Mme Lapierre,
I find it a little confusing that your email says that standards
makers will present what the signalling of VoIP will look like,
and that your agenda refers to the session as an H.323/IP workshop,
yet none of the scheduled talks seem to talk about H.323. Rather
there seems to be a focus on the gateway control protocols (SGCP
and IPDC) which as you know, are being pushed by some parties as
replacements for H.323. Can you clear up my confusion?
Regards,
Dave Walker
Mitel …
[View More]Corporation
Ontario, CANADA
Martine.Lapierre(a)alcatel.fr wrote:
>
> Good evening,
>
> please find attached an invitation to a workshop on VoIP where key
> VoIP experts will be present.
> Standards makers will present what the signalling of VoIP will look
> like, and its impact on the network architecture.
> IP / VoIP manufacturers will be there.
> Operators will be discussing how and when they see VoIP in their
> networks.
> I will be happy to chair this session.
>
> The workshop is sponsored by the TINA consortium, so that the entry is
> free.
> Nevertheless, we need to know the number of persons who will attend to
> determine the room size, so be kind enough to register if you or a
> representant of your company are coming.
>
> Martine Lapierre
> 3 times a year, all telecom operators, telecom manufacturers and IT/IP manufacturers
> use to meet in the TINA Consortium Technical Forum for a week of worgroups exchanges,
> Request For Pproposals examinations, including an open workshop.
>
> EURESCOM and the TINA Consortium are pleased to invite you to the October 98 open
> workshop on H323/IP, that will focus mainly on 2 issues:
> - The re-use of the existing vocal services unto a VoIP network
> - The network architecture and signalling for an IP based vocal and data operator.
>
> During the afternoon, four presentations and an open discussion will take place.
>
> AGENDA:
>
>
> Introduction Martine LAPIERRE,TINA-C president
>
> Christian HUITEMA, Bellcore : Controling routers with the SGCP protocol defined by
> Bellcore and Cisco; the IETSF group; VoIP network architectures
>
> Ike ELLIOT, Level3 and Pete OCONNELL, Alcatel: Controling VoIP networks with IPDC;
> associated network architectures
>
> Didier GUY (France Telecom): what could be the future of the telecom Switches; can TINA
> bring something to VOIP?
>
> William NAVARRO (ETSI/UMTS/TFO Leader, Nortel): introducing VoIP in mobile networks:
> the Tandem Free Operations signalling, and the IP based UMTS Phase 2 possible network
> architecture
>
> Question and Answer Session.
>
[View Less]
