tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5973

 
 
 

NAT/Firewall NSIS Signaling Layer Protocol (NSLP)

Part 5 of 5, p. 76 to 90
Prev RFC Part

 


prevText      Top      Up      ToC       Page 76 
6.  IAB Considerations on UNSAF

   UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a
   process at originating endpoints that attempts to determine or fix
   the address (and port) by which they are known to another endpoint.
   UNSAF proposals, such as STUN [RFC5389] are considered as a general
   class of workarounds for NAT traversal and as solutions for scenarios
   with no middlebox communication.

   This memo specifies a path-coupled middlebox communication protocol,
   i.e., the NSIS NATFW NSLP.  NSIS in general and the NATFW NSLP are
   not intended as a short-term workaround, but more as a long-term
   solution for middlebox communication.  In NSIS, endpoints are
   involved in allocating, maintaining, and deleting addresses and ports
   at the middlebox.  However, the full control of addresses and ports
   at the middlebox is at the NATFW NSLP daemon located at the
   respective NAT.

Top      Up      ToC       Page 77 
   Therefore, this document addresses the UNSAF considerations in
   [RFC3424] by proposing a long-term alternative solution.

7.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the
   NATFW NSLP, in accordance with BCP 26, RFC 5226 [RFC5226].

   The NATFW NSLP requires IANA to create a number of new registries:

   o  NATFW NSLP Message Types

   o  NATFW NSLP Header Flags

   o  NSLP Response Codes

   It also requires registration of new values in a number of
   registries:

   o  NSLP Message Objects

   o  NSLP Identifiers (under GIST Parameters)

   o  Router Alert Option Values (IPv4 and IPv6)

7.1.  NATFW NSLP Message Type Registry

   The NATFW NSLP Message Type is an 8-bit value.  The allocation of
   values for new message types requires IETF Review.  Updates and
   deletion of values from the registry are not possible.  This
   specification defines four NATFW NSLP message types, which form the
   initial contents of this registry.  IANA has added these four NATFW
   NSLP Message Types: CREATE (0x1), EXTERNAL (0x2), RESPONSE (0x3), and
   NOTIFY (0x4). 0x0 is Reserved.  Each registry entry consists of
   value, description, and reference.

7.2.  NATFW NSLP Header Flag Registry

   NATFW NSLP messages have a message-specific 8-bit flags/reserved
   field in their header.  The registration of flags is subject to IANA
   registration.  The allocation of values for flag types requires IETF
   Review.  Updates and deletion of values from the registry are not
   possible.  This specification defines only two flags in Section 4.1,
   the P flag (bit 8) and the E flag (bit 9).  Each registry entry
   consists of value, bit position, description (containing the section
   number), and reference.

Top      Up      ToC       Page 78 
7.3.  NSLP Message Object Registry

   In Section 4.2 this document defines 9 objects for the NATFW NSLP:
   NATFW_LT, NATFW_EXTERNAL_IP, NATFW_EXTERNAL_BINDING, NATFW_EFI,
   NATFW_INFO, NATFW_NONCE, NATFW_MSN, NATFW_DTINFO, NATFW_ICMP_TYPES.
   IANA has assigned values for them from the NSLP Message Objects
   registry.

7.4.  NSLP Response Code Registry

   In addition, this document defines a number of Response Codes for the
   NATFW NSLP.  These can be found in Section 4.2.5 and have been
   assigned values from the NSLP Response Code registry.  The allocation
   of new values for Response Codes requires IETF Review.  IANA has
   assigned values for them as given in Section 4.2.5 for the error
   class and also for the number of responses values per error class.
   Each registry entry consists of response code, value, description,
   and reference.

7.5.  NSLP IDs and Router Alert Option Values

   GIST NSLPID

   This specification defines an NSLP for use with GIST and thus
   requires an assigned NSLP identifier.  IANA has added one new value
   (33) to the NSLP Identifiers (NSLPID) registry defined in [RFC5971]
   for the NATFW NSLP.

   IPv4 and IPv6 Router Alert Option (RAO) value

   The GIST specification also requires that each NSLP-ID be associated
   with specific Router Alert Option (RAO) value.  For the purposes of
   the NATFW NSLP, a single IPv4 RAO value (65) and a single IPv6 RAO
   value (68) have been allocated.

8.  Acknowledgments

   We would like to thank the following individuals for their
   contributions to this document at different stages:

   o  Marcus Brunner and Henning Schulzrinne for their work on IETF
      documents that led us to start with this document;

   o  Miquel Martin for his large contribution on the initial version of
      this document and one of the first prototype implementations;

   o  Srinath Thiruvengadam and Ali Fessi work for their work on the
      NAT/firewall threats document;

Top      Up      ToC       Page 79 
   o  Henning Peters for his comments and suggestions;

   o  Ben Campbell as Gen-ART reviewer;

   o  and the NSIS working group.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5971]  Schulzrinne, H. and R. Hancock, "GIST: General Internet
              Signalling Transport", RFC 5971, October 2010.

   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              August 1996.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

9.2.  Informative References

   [RFC4080]  Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
              Bosch, "Next Steps in Signaling (NSIS): Framework",
              RFC 4080, June 2005.

   [RFC3726]  Brunner, M., "Requirements for Signaling Protocols",
              RFC 3726, April 2004.

   [RFC5974]  Manner, J., Karagiannis, G., and A. McDonald, "NSIS
              Signaling Layer Protocol (NSLP) for Quality-of-Service
              Signaling", RFC 5974, October 2010.

   [RFC5866]  Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A.,
              and G. Zorn, "Diameter Quality-of-Service Application",
              RFC 5866, May 2010.

   [RFC5978]  Manner, J., Bless, R., Loughney, J., and E. Davies, "Using
              and Extending the NSIS Protocol Family", RFC 5978,
              October 2010.

   [RFC3303]  Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
              A. Rayhan, "Middlebox communication architecture and
              framework", RFC 3303, August 2002.

Top      Up      ToC       Page 80 
   [RFC4081]  Tschofenig, H. and D. Kroeselberg, "Security Threats for
              Next Steps in Signaling (NSIS)", RFC 4081, June 2005.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, February 2002.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
              Self-Address Fixing (UNSAF) Across Network Address
              Translation", RFC 3424, November 2002.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC3198]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
              M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
              J., and S. Waldbusser, "Terminology for Policy-Based
              Management", RFC 3198, November 2001.

   [RFC3520]  Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
              "Session Authorization Policy Element", RFC 3520,
              April 2003.

   [RFC3521]  Hamer, L-N., Gage, B., and H. Shieh, "Framework for
              Session Set-up with Media Authorization", RFC 3521,
              April 2003.

   [rsvp-firewall]
              Roedig, U., Goertz, M., Karten, M., and R. Steinmetz,
              "RSVP as firewall Signalling Protocol", Proceedings of the
              6th IEEE Symposium on Computers and Communications,
              Hammamet, Tunisia, pp. 57 to 62, IEEE Computer Society
              Press, July 2001.

Top      Up      ToC       Page 81 
Appendix A.  Selecting Signaling Destination Addresses for EXTERNAL

   As with all other message types, EXTERNAL messages need a reachable
   IP address of the data sender on the GIST level.  For the path-
   coupled MRM, the source-address of GIST is the reachable IP address
   (i.e., the real IP address of the data sender, or a wildcard).  While
   this is straightforward, it is not necessarily so for the loose-end
   MRM.  Many applications do not provide the IP address of the
   communication counterpart, i.e., either the data sender or both a
   data sender and receiver.  For the EXTERNAL messages, the case of
   data sender is of interest only.  The rest of this section gives
   informational guidance about determining a good destination-address
   of the LE-MRM in GIST for EXTERNAL messages.

   This signaling destination address (SDA, the destination-address in
   GIST) can be the data sender, but for applications that do not
   provide an address upfront, the destination IP address has to be
   chosen independently, as it is unknown at the time when the NATFW
   NSLP signaling has to start.  Choosing the 'correct' destination IP
   address may be difficult and it is possible that there is no 'right
   answer' for all applications relying on the NATFW NSLP.

   Whenever possible, it is RECOMMENDED to chose the data sender's IP
   address as the SDA.  It is necessary to differentiate between the
   received IP addresses on the data sender.  Some application-level
   signaling protocols (e.g., SIP) have the ability to transfer multiple
   contact IP addresses of the data sender.  For instance, private IP
   addresses, public IP addresses at a NAT, and public IP addresses at a
   relay.  It is RECOMMENDED to use all non-private IP addresses as
   SDAs.

   A different SDA must be chosen, if the IP address of the data sender
   is unknown.  This can have multiple reasons: the application-level
   signaling protocol cannot determine any data sender IP address at
   this point in time or the data receiver is server behind a NAT, i.e.,
   accepting inbound packets from any host.  In this case, the NATFW
   NSLP can be instructed to use the public IP address of an application
   server or any other node.  Choosing the SDA in this case is out of
   the scope of the NATFW NSLP and depends on the application's choice.
   The local network can provide a network-SDA, i.e., an SDA that is
   only meaningful to the local network.  This will ensure that GIST
   packets with destination-address set to this network-SDA are going to
   be routed to an edge-NAT or edge-firewall.

Top      Up      ToC       Page 82 
Appendix B.  Usage of External Binding Addresses

   The NATFW_EXTERNAL_BINDING object carries information, which has a
   different utility to the information carried within the
   NATFW_EXTERNAL_IP object.  The NATFW_EXTERNAL_IP object has the
   public IP address and potentially port numbers that can be used by
   the application at the NI to be reachable via the public Internet.
   However, there are cases in which various NIs are located behind the
   same public NAT, but are subject to a multi-level NAT deployment, as
   shown in Figure 35.  They can use their public IP address port
   assigned to them to communicate between each other (e.g., NI with NR1
   and NR2) but they are forced to send their traffic through the edge-
   NAT, even though there is a shorter way possible.

       NI --192.168.0/24-- NAT1--10.0.0.0/8--NAT2 Internet (public IP)
                                |
       NR1--192.168.0/24-- NAT3--
                                |
                                NR2 10.1.2.3

                    Figure 35: Multi-Level NAT Scenario

   Figure 35 shows an example that is explored here:

   1.  NI -> NR1: Both NI and NR1 send EXTERNAL messages towards NAT2
       and get an external address+port binding.  Then, they exchange
       that external binding and all traffic gets pinned to NAT2 instead
       of taking the shortest path by NAT1 to NAT3 directly.  However,
       to do that, NR1 and NI both need to be aware that they also have
       the address on the external side of NAT1 and NAT3, respectively.
       If ICE is deployed and there is actually a STUN server in the
       10/8 network configured, it is possible to get the shorter path
       to work.  The NATFW NSLP provides all external addresses in the
       NATFW_EXTERNAL_BINDING towards the public network it could allow
       for optimizations.

   2.  For the case NI -> NR2 is even more obvious.  Pinning this to
       NAT2 is an important fallback, but allowing for trying for a
       direct path between NAT1 and NAT3 might be worth it.

   Please note that if there are overlapping address domains between NR
   and the public Internet, the regular routing will not necessary allow
   sending the packet to the right domain.

Top      Up      ToC       Page 83 
Appendix C.  Applicability Statement on Data Receivers behind Firewalls

   Section 3.7.2 describes how data receivers behind middleboxes can
   instruct inbound firewalls/NATs to forward NATFW NSLP signaling
   towards them.  Finding an inbound edge-NAT in an address environment
   with NAT'ed addresses is quite easy.  It is only required to find
   some edge-NAT, as the data traffic will be route-pinned to the NAT.
   Locating the appropriate edge-firewall with the PC-MRM sent inbound
   is difficult.  For cases with a single, symmetric route from the
   Internet to the data receiver, it is quite easy; simply follow the
   default route in the inbound direction.

                             +------+                  Data Flow
                     +-------| EFW1 +----------+     <===========
                     |       +------+       ,--+--.
                  +--+--+                  /       \
          NI+-----| FW1 |                 (Internet )----NR+/NI/DS
          NR      +--+--+                  \       /
                     |       +------+       `--+--'
                     +-------| EFW2 +----------+
                             +------+

           ~~~~~~~~~~~~~~~~~~~~~>
             Signaling Flow

            Figure 36: Data Receiver behind Multiple Firewalls
                            Located in Parallel

   When a data receiver, and thus NR, is located in a network site that
   is multihomed with several independently firewalled connections to
   the public Internet (as shown in Figure 36), the specific firewall
   through which the data traffic will be routed has to be ascertained.
   NATFW NSLP signaling messages sent from the NI+/NR during the
   EXTERNAL message exchange towards the NR+ must be routed by the NTLP
   to the edge-firewall that will be passed by the data traffic as well.
   The NTLP would need to be aware about the routing within the Internet
   to determine the path between the DS and DR.  Out of this, the NTLP
   could determine which of the edge-firewalls, either EFW1 or EFW2,
   must be selected to forward the NATFW NSLP signaling.  Signaling to
   the wrong edge-firewall, as shown in Figure 36, would install the
   NATFW NSLP policy rules at the wrong device.  This causes either a
   blocked data flow (when the policy rule is 'allow') or an ongoing
   attack (when the policy rule is 'deny').  Requiring the NTLP to know
   all about the routing within the Internet is definitely a tough
   challenge and usually not possible.  In a case as described, the NTLP
   must basically give up and return an error to the NSLP level,
   indicating that the next hop discovery is not possible.

Top      Up      ToC       Page 84 
Appendix D.  Firewall and NAT Resources

   This section gives some examples on how NATFW NSLP policy rules could
   be mapped to real firewall or NAT resources.  The firewall rules and
   NAT bindings are described in a natural way, i.e., in a way that one
   will find in common implementations.

D.1.  Wildcarding of Policy Rules

   The policy rule/MRI to be installed can be wildcarded to some degree.
   Wildcarding applies to IP address, transport layer port numbers, and
   the IP payload (or next header in IPv6).  Processing of wildcarding
   splits into the NTLP and the NATFW NSLP layer.  The processing at the
   NTLP layer is independent of the NSLP layer processing and per-layer
   constraints apply.  For wildcarding in the NTLP, see Section 5.8 of
   [RFC5971].

   Wildcarding at the NATFW NSLP level is always a node local policy
   decision.  A signaling message carrying a wildcarded MRI (and thus
   policy rule) arriving at an NSLP node can be rejected if the local
   policy does not allow the request.  For instance, take an MRI with IP
   addresses set (not wildcarded), transport protocol TCP, and TCP port
   numbers completely wildcarded.  If the local policy allows only
   requests for TCP with all ports set and not wildcarded, the request
   is going to be rejected.

D.2.  Mapping to Firewall Rules

   This section describes how a NSLP policy rule signaled with a CREATE
   message is mapped to a firewall rule.  The MRI is set as follows:

   o  network-layer-version=IPv4

   o  source-address=192.0.2.100, prefix-length=32

   o  destination-address=192.0.50.5, prefix-length=32

   o  IP-protocol=UDP

   o  L4-source-port=34543, L4-destination-port=23198

   The NATFW_EFI object is set to action=allow and sub_ports=0.

   The resulting policy rule (firewall rule) to be installed might look
   like: allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198.

Top      Up      ToC       Page 85 
D.3.  Mapping to NAT Bindings

   This section describes how a NSLP policy rule signaled with an
   EXTERNAL message is mapped to a NAT binding.  It is assumed that the
   EXTERNAL message is sent by a NI+ located behind a NAT and does
   contain a NATFW_DTINFO object.  The MRI is set following using the
   signaling destination address, since the IP address of the real data
   sender is not known:

   o  network-layer-version=IPv4

   o  source-address= 192.168.5.100

   o  destination-address=SDA

   o  IP-protocol=UDP

   The NATFW_EFI object is set to action=allow and sub_ports=0.  The
   NATFW_DTINFO object contains these parameters:

   o  P=1

   o  dest prefix=0

   o  protocol=UDP

   o  dst port number = 20230, src port number=0

   o  src IP=0.0.0.0

   The edge-NAT allocates the external IP 192.0.2.79 and port 45000.

   The resulting policy rule (NAT binding) to be installed could look
   like: translate udp from any to 192.0.2.79 port=45000 to
   192.168.5.100 port=20230.

D.4.  NSLP Handling of Twice-NAT

   The dynamic configuration of twice-NATs requires application-level
   support, as stated in Section 2.5.  The NATFW NSLP cannot be used for
   configuring twice-NATs if application-level support is needed.
   Assuming application-level support performing the configuration of
   the twice-NAT and the NATFW NSLP being installed at this devices, the
   NATFW NSLP must be able to traverse it.  The NSLP is probably able to
   traverse the twice-NAT, as is any other data traffic, but the flow
   information stored in the NTLP's MRI will be invalidated through the
   translation of source and destination IP addresses.  The NATFW NSLP
   implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP

Top      Up      ToC       Page 86 
   signaling messages as any other NATFW NSLP node does.  For the given
   signaling flow, the NATFW NSLP node MUST look up the corresponding IP
   address translation and modify the NTLP/NSLP signaling accordingly.
   The modification results in an updated MRI with respect to the source
   and destination IP addresses.

Appendix E.  Example for Receiver Proxy Case

   This section gives an example on how to use the NATFW NLSP for a
   receiver behind a NAT, where only the receiving side is NATFW NSLP
   enabled.  We assume FTP as the application to show a working example.
   An FTP server is located behind a NAT, as shown in Figure 5, and uses
   the NATFW NSLP to allocate NAT bindings for the control and data
   channel of the FTP protocol.  The information about where to reach
   the server is communicated by a separate protocol (e.g., email, chat)
   to the DS side.

Top      Up      ToC       Page 87 
                   Public Internet                 Private Address
                                                        Space
      FTP Client                                            FTP Server

       DS                          NAT                         NI+
       |                           |                            |
       |                           |  EXTERNAL                  |
       |                           |<---------------------------|(1)
       |                           |                            |
       |                           |RESPONSE[Success]           |
       |                           |--------------------------->|(2)
       |                           |CREATE                      |
       |                           |--------------------------->|(3)
       |                           |RESPONSE[Success]           |
       |                           |<---------------------------|(4)
       |                           |                            |
       |                           | <Use port=XYZ, IP=a.b.c.d> |
       |<=======================================================|(5)
       |FTP control port=XYZ       | FTP control port=21        |
       |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(6)
       |                           |                            |
       |  FTP control/get X        |   FTP control/get X        |
       |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(7)
       |                           |  EXTERNAL                  |
       |                           |<---------------------------|(8)
       |                           |                            |
       |                           |RESPONSE[Success]           |
       |                           |--------------------------->|(9)
       |                           |CREATE                      |
       |                           |--------------------------->|(10)
       |                           |RESPONSE[Success]           |
       |                           |<---------------------------|(11)
       |                           |                            |
       | Use port=FOO, IP=a.b.c.d  |  Use port=FOO, IP=a.b.c.d  |
       |<~~~~~~~~~~~~~~~~~~~~~~~~~~|<~~~~~~~~~~~~~~~~~~~~~~~~~~~|(12)
       |                           |                            |
       |FTP data to port=FOO       | FTP data to port=20        |
       |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(13)


                           Figure 37: Flow Chart

Top      Up      ToC       Page 88 
   1.   EXTERNAL request message sent to NAT, with these objects:
        signaling session lifetime, extended flow information object
        (rule action=allow, sub_ports=0), message sequence number
        object, nonce object (carrying nonce for CREATE), and the data
        terminal information object (I/P-flags set, sender prefix=0,
        protocol=TCP, DR port number = 21, DS's IP address=0); using the
        LE-MRM.  This is used to allocate the external binding for the
        FTP control channel (TCP, port 21).

   2.   Successful RESPONSE sent to NI+, with these objects: signaling
        session lifetime, message sequence number object, information
        code object ('Success':2), external address object (port=XYZ,
        IPv4 addr=a.b.c.d).

   3.   The NAT sends a CREATE towards NI+, with these objects:
        signaling session lifetime, extended flow information object
        (rule action=allow, sub_ports=0), message sequence number
        object, nonce object (with copied value from (1)); using the PC-
        MRM (src-IP=a.b.c.d, src-port=XYZ, dst-IP=NI+, dst-port=21,
        downstream).

   4.   Successful RESPONSE sent to NAT, with these objects: signaling
        session lifetime, message sequence number object, information
        code object ('Success':2).

   5.   The application at NI+ sends external NAT binding information to
        the other end, i.e., the FTP client at the DS.

   6.   The FTP client connects the FTP control channel to port=XYZ,
        IP=a.b.c.d.

   7.   The FTP client sends a get command for file X.

   8.   EXTERNAL request message sent to NAT, with these objects:
        signaling session lifetime, extended flow information object
        (rule action=allow, sub_ports=0), message sequence number
        object, nonce object (carrying nonce for CREATE), and the data
        terminal information object (I/P-flags set, sender prefix=32,
        protocol=TCP, DR port number = 20, DS's IP address=DS-IP); using
        the LE-MRM.  This is used to allocate the external binding for
        the FTP data channel (TCP, port 22).

   9.   Successful RESPONSE sent to NI+, with these objects: signaling
        session lifetime, message sequence number object, information
        code object ('Success':2), external address object (port=FOO,
        IPv4 addr=a.b.c.d).

Top      Up      ToC       Page 89 
   10.  The NAT sends a CREATE towards NI+, with these objects:
        signaling session lifetime, extended flow information object
        (rule action=allow, sub_ports=0), message sequence number
        object, nonce object (with copied value from (1)); using the PC-
        MRM (src-IP=a.b.c.d, src-port=FOO, dst-IP=NI+, dst-port=20,
        downstream).

   11.  Successful RESPONSE sent to NAT, with these objects: signaling
        session lifetime, message sequence number object, information
        code object ('Success':2).

   12.  The FTP server responses with port=FOO and IP=a.b.c.d.

   13.  The FTP clients connects the data channel to port=FOO and
        IP=a.b.c.d.

Top      Up      ToC       Page 90 
Authors' Addresses

   Martin Stiemerling
   NEC Europe Ltd. and University of Goettingen
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 (0) 6221 4342 113
   EMail: Martin.Stiemerling@neclab.eu
   URI:   http://www.stiemerling.org


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   EMail: Hannes.Tschofenig@nsn.com
   URI:   http://www.tschofenig.priv.at


   Cedric Aoun
   Consultant
   Paris, France

   EMail: cedaoun@yahoo.fr


   Elwyn Davies
   Folly Consulting
   Soham
   UK

   Phone: +44 7889 488 335
   EMail: elwynd@dial.pipex.com