ICT-ISS 2008 ET-CTS (EUDCS) Report

1. ICT-ISS 2008ET-CTS (EUDCS) Report Jean-François Gagnon Director, Telecommunications Chief Information Officer Branch Environment Canada . 2121 Trans-Canada Highway Dorval, Québec Canada, H9P 1J3 514-421-4658 jean-francois.gagnon@ec.gc.ca

2. ET-CTS Group, Toulouse, May 2008 ICT-ISS – Genève

3. ET Members & Participants ICT-ISS – Genève

4. REVIEW OF THE CURRENT STATUS OF IMPLEMENTATION OF TCP/IP PROCEDURES AND APPLICATIONS AT GTS CENTRES • Reports from: • RTH Beijing - RTH Tokyo • RTH Toulouse - RTH Melbourne • RTH Washington - RTH Brasilia • RTH Offenbach - RTH Wellington • NMC Ankara (paper) - NMC Hong Kong • NMC China - ECMWF • ASECNA http://www.wmo.int/pages/prog/www/ISS/Meetings/ET-CTS_Toulouse2008/documents.html • Two remaining X.25 circuits connecting Toulouse to Dakar and Niamey were planned to be replaced by TCP/IP circuits in summer • Using Internet as a GTS circuit • Significant number of centres. • Because of risks, ET restated that should be considered case by case, when no other affordable means available • Wellington and Melbourne indicated that in many RA V islands, Internet is not reliable at all. Email is the most widely used protocol. Small islands prove to pose very special problems that even the Internet can’t solve. • Using Encryption: • Discussed encryption to face security threats. The ET decided it was premature to make any recommendation (considerable burden on data processors, significant transmission delays) ICT-ISS – Genève

5. REVIEW OF THE CURRENT STATUS OF IMPLEMENTATION OF TCP/IP PROCEDURES AND APPLICATIONS AT GTS CENTRES (cont’d) • DIFMET • New dissemination system developed by France • No plans to end RETIM transmissions for the foreseeable future. • Tsunami warning considerations • At times sent more than once (from different sources or sometimes from the same source), causes confusion and unnecessary over-reaction. Efforts should be made by the concerned countries to mitigate this problem, as the receiving countries do not always have the local means to address this problem easily. • Noted that maximum delivery delay requirement of tsunami warnings is now to be 2 minutes. This is challenging: old delivery target maximum was 15 minutes. A small sampling of messages was looked at by the Secretariat, which then found that the delays varied between 2 to 20 minutes or even more in some regions. The meeting discussed the issue, which pertains to the handling of priority messages within the various traffic switches, to the limited bandwidth of some GTS circuits and to the number of system nodes that need to be traversed. • Noted that the sea level data should be treated as priority messages as they are often critical to ascertain the emergence or progress of a tsunami. Furthermore, these messages leave little time to react. ET-CTS recommended that this matter is addressed by appropriate ET (ET-OI). ICT-ISS – Genève

6. REVIEW OF THE CURRENT STATUS OF IMPLEMENTATION OF TCP/IP PROCEDURES AND APPLICATIONS AT GTS CENTRES (cont’d) • Washington Message Switching System was upgraded. The new design allows switching of parallel messages flows, and that these features could be used to implement different switching priorities. It was noted that the backup system was operational, although actual backup activation still required manual intervention. • RA III and cloud 1: • Brasilia and Buenos Aires have not yet joined Cloud I • No progress has been reached towards the implementation of the RA III RMDCN due to difficulties of Members of the Region to conclude the National Contracts with the selected provider (OBS) • Many GTS circuits are implemented via Internet. This may have significantly contributed to discourage the implementation of the managed network. • RA VI RMDCN backup • RMDCN backup service using ISDN links is becoming less appropriate as they are in many cases too small compared to the primary links • ECMWF is investigating IPSec VPN solutions using the Internet ICT-ISS – Genève

7. RECOMMENDED PRACTICES FOR DATA COMMUNICATION AND ACCESS PROCEDURES

8. IPv6 • ECMWF conducted tests using the existing IPv6 research Internet • Successful connectivity was immediately achieved between CMA (China), CNR (Italy), DWD (Germany), JMA (Japan), KNMI (The Netherlands), SMHI (Sweden) and ECMWF • Standard routers used with the same hardware and firmware found in a normal IPv4 network, simply reconfigured to use the IPv6 stacks already in place • This indicates that the products are ready. • IPv6 address scheme • Is very different than IPv4 • Most IPv6 configuration is fully automatic • Thus more unknowns in configuration of the network, which may lead to more difficult troubleshooting • Training will be required before implementation. • Performance • Comparisons not very conclusive as the IPv4 and IPv6 clouds are very different • No indication that IPv6 is slower at this time. • TCP/IP Applications • Most (e. g. FTP, Telnet, SSH) are IPv6 ready, including the basic troubleshooting ones (Ping, Traceroute, Tcpdump) ICT-ISS – Genève

9. IPv6 cont’d • Security • Since addressing is automatic, topology to setup firewalls would be very different than in the IPv4 world • Difficult to establish access list rules as IPv6 addresses may even change during the life of a network. • Applications may require more security to compensate. • This will need further investigation. • Migration considerations • ECMWF plans to test dual stack implementation in the future to begin the evaluation of migration plans. • Dual stacks may be simplest approach since the existing DNS applications report both IPv4 and IPv6 addresses • TCP/IP applications should give preference to IPv6 addresses • Computers could be connected to both an IPv4 and IPv6 network and maintain connectivity with both environments, using the IPv6 stacks in priority. • Still too early for any recommendation on the timeframe for IPv6 to become a viable solution for WMO purposes • Tracking market acceptance remains an important activity for ET-CTS. • Very few countries or organization have announced firm plans to migrate to IPv6 officially, apart from movements to do so in some in some regions, principally in research networks. • New application development • Ensure that due consideration given to the very real possibility of using IPv6 in the future • Ensure coding of telecommunication applications does not hardcode any IPv4 features (e. g. address space of 32 bits) ICT-ISS – Genève

10. Authentication mechanisms • SIMDAT Authentication is based on Public Key Infrastructure (PKI) • Required special software to be developed • Defines domains (for example for each VGISC). Users and data are defined to be part of certain domains as required. Data access is granted when the system reports that a particular user is allowed to access data in a given domain. • SIMDAT can be downloaded free of charge under the Apache license from the SIMDAT project page at the ECMWF Website. ICT-ISS – Genève

11. Data availability using blog based technology • May be quite promising as a mechanism complementary to the GTS for notification and dissemination of priority messages such as tsunami warnings • Feasibility tests being conducted between Japan and Brazil • Over the Internet • Successful synchronization of SYNOP and TEMP within 2 minutes • Successful synchronization of some JM NWP files within 3 minutes (up to 70MBytes) • Notification alone within 20 seconds • Technology works but still far from being a procedure for priority messages (issues of message length, user interface, etc.) ICT-ISS – Genève

12. GUIDANCE FOR IMPLEMENTATION OF DATA COMMUNICATION FACILITIES (GTS & INTERNET) AT WWW CENTRES

13. Guide on IT Security • Analysis by security experts from RTH Washington indicated that the guide was very useful and contained all needed guidance material. • Some sections to be updated and the new version will be finalized by a subgroup established by ET-CTS for this purpose (not complete) ICT-ISS – Genève

14. Guide on Internet Practices • Input provided by Hong Kong, China and Ankara to update the Guide • Subgroup of ET-CTS was established to finalize the wording to update this guide (complete). • Overlap of this guide with Guide on IT Security was addressed with recommendation that the Guide on ITS was to be considered the authoritative security document. ICT-ISS – Genève

15. Filenaming convention • It was noted that the filenaming convention is successful, easy to process in switches and in use in at least 7 countries. • No further work necessary at the moment • Some comments and/or new requirements may arise from work carried out in the satellite community which would have to be considered by ET-CTS (eg. ATOVS) • Some implementations make redundant use of the free format field to carry information that is in other fields of the filename. Although this results on very long names to process, it is not necessarily a serious impairment. ICT-ISS – Genève

16. IP VPN over the Internet • Extensively tested by ECMWF/RMDCN as possible replacement for ISDN in backup circuits which are no longer adequate in MPLS world • Attractive solution for any-to-any connectivity • The approach proved valid but some issues are still not completely solved • Interoperability with boxes from different vendors is difficult, so a one-vendor approach is recommended. • Cisco’s proprietary DMVPN also to be studied: provides control to dynamic establishment of any-to-any VPN tunnels • Noted that cheaper hardware to implement IP-VPN networks is easily available today (around US$ 250.00), and may be of interest for special cases. • Guide on IP-VPN review (version 2 - completed) • No new material, removed outdated references (eg. Frame relay, old URLs, etc.) • Further review recommended after ECMWF/RMDCN tests complete ICT-ISS – Genève

17. Challenges for ET-EUDCS • Several WIS questions unanswered, and some feeling that ET-CTS(EUDCS) doesn’t live to expectations as leaders in the field • Lack of communication with other WIS experts leads to “requirements-solutions” model rather than “engaged in architecture” • Joint EUDCS and DCS ETs is a great synergy, but resulted in less experts while still many tasks to address • Availability of resources (time from participants) • Scheduling of meetings, ET meeting should be in year between ICT-ISS • Would allow for more distributed effort over time ICT-ISS – Genève

18. Thanks • I wish to thank ET-CTS members and the secretariat (JA de Sousa Brito) for their combined efforts in making this work possible ICT-ISS – Genève

19. Summary of ad-hoc working groups and document responsibilities ICT-ISS – Genève