1 NSIS Interim Meeting 2005, Munich

GIMPS Implementation

Bernd Schloer, Christian Dickmann, Andreas Westermaier

Xiaoming Fu, Hannes Tschofenig, Elwyn Davies

May 2005

2 NSIS Interim Meeting 2005, Munich

• Project overview

• General implementation approach

• Important key elements

• Message-to-FSM distributor

• Finite state machine

• NTLP-to-NSLP API

• TLS over TCP as transport

• Diagnostics tool (Ping tool)

Outline

3 NSIS Interim Meeting 2005, Munich

• Started in November 2004

• Co-operation between Göttingen, Munich, and INT (France)

• Current developers:

• Core team: Bernd Schloer, Christian Dickmann (Göttingen), Andreas Westermaier (Munich)

• Contributors: Henning Peters, Ingo Juchem, Sebastian Willert, Nils Röttger (Göttingen), Alex Zrim, Tseno Tsenov (Munich), Julien Abeille, Youssef Abidi (France)

Project overview

4 NSIS Interim Meeting 2005, Munich

Current status

• Basic funcitons of GIMPS-05: implemented• including basic API• currently IPv4 only

• Ping test tool: supported

• Ethereal tool for monitoring GIMPS messages: developed

• A running testbed

• Basic TLS support

5 NSIS Interim Meeting 2005, Munich

Design overviewMessage routing state (MRS) Table

Session #1 Sender FSM

Receiver FSM

Session #3 Sender FSM

Receiver FSM

Session #2 Sender FSM

Receiver FSM

Message asssociation (MA) Table

MA #1UDP Socket

MA #2TCP Socket

MA #3TCP Socket

MA #4TCP/TLS Socket

Eventloop RAW Socket

Message Parser

Message <-> FSMDistributor

API

6 NSIS Interim Meeting 2005, Munich

Message-to-FSM DistributorMessage routing state (MRS) Table

Session #1 Sender FSM

Receiver FSM

Session #3 Sender FSM

Receiver FSM

Session #2 Sender FSM

Receiver FSM

Message asssociation (MA) Table

MA #1UDP Socket

MA #2TCP Socket

MA #3TCP Socket

MA #4TCP/TLS Socket

Eventloop RAW Socket

Message Parser

Message <-> FSMDistributor

API

7 NSIS Interim Meeting 2005, Munich

• Check if associated NSLP application is supported by this Node – bypass if not

• Lookup the flow. Direction determines if senderFSM or receiverFSM is used

• Create flow and/or FSM if not existing already

• Validate message

• Trigger event of the FSM and pass the message

Message-to-FSM Distributor

8 NSIS Interim Meeting 2005, Munich

Design overviewMessage routing state (MRS) Table

Session #1 Sender FSM

Receiver FSM

Session #3 Sender FSM

Receiver FSM

Session #2 Sender FSM

Receiver FSM

Message asssociation (MA) Table

MA #1UDP Socket

MA #2TCP Socket

MA #3TCP Socket

MA #4TCP/TLS Socket

Eventloop RAW Socket

Message Parser

Message <-> FSMDistributor

API

9 NSIS Interim Meeting 2005, Munich

• draft-fu-nsis-ntlp-statemachine-02 serves as basis for our implementation

• Process message according to current running state

• Generate message in response

• Maybe pass message to higher layer

• Maintain message associations (MA)

• Setup message associations

• Manage reuse of message associations

• Maintain message routing state (MRS)

• Maintain timers

• Send and receive refreshing Messages

State machine

10 NSIS Interim Meeting 2005, Munich

APIMessage routing state (MRS) Table

Session #1 Sender FSM

Receiver FSM

Session #3 Sender FSM

Receiver FSM

Session #2 Sender FSM

Receiver FSM

Message asssociation (MA) Table

MA #1UDP Socket

MA #2TCP Socket

MA #3TCP Socket

MA #4TCP/TLS Socket

Eventloop RAW Socket

Message Parser

Message <-> FSMDistributor

API

11 NSIS Interim Meeting 2005, Munich

• Communication with NSLP layer

• Combination of unix sockets and shared memory

• Several NSLP application may connect simultaneously

• API calls may trigger FSM events

• FSM passes information and incoming message the NSLP application through the API

API

12 NSIS Interim Meeting 2005, Munich

TLS Support

• Used the OpenSSL library

• TLS handshake triggered by corresponding Stack Proposal in GIMPS-Query

• Client authentication currently optional

• No certificate revokation checks

• NSLP application has currently no possibility to choose desired cipher suite or if it requires client authentication

• No support to inform the NSLP application about possible connection failures

13 NSIS Interim Meeting 2005, Munich

Lessons learned

• More accurate understanding of GIMPS specifications through work on implementation

• E.g., stack proposal, message state refresh

• How to implement it in software systems

• Implementing an efficient FSM• We took a FSM framework used in the Linux kernel 2.6

• Current Hashtable implementation is basic • For real environment a more scalable solution might be

necessary

• Ethereal dissector helps debugging message format

14 NSIS Interim Meeting 2005, Munich

Open issues

• Stack-Proposal in Response message

• Switching from TCP to TLS

• How to choose the peer identity?

• Higher layer information specification

• Route change cases

• GIMPS Hop count

• WaitConfirm state for Query FSM/spec issue

• State repository for upstreaming and downstreaming in middle node

15 NSIS Interim Meeting 2005, Munich

Discussions

• Comments, suggestions welcome!