1 TCP/IP based TML (Transport Mapping Layer) for ForCES Protocol Hormuzd Khosravi Shuchi Chawla Furquan Ansari Jon Maloy 62 nd IETF Meeting, Minneapolis

2 Topics  TCP/IP TML Overview  CE-FE Communication Channels  Unicast and Multicast Messaging  TML Messaging  TML Service Interface  TML Service Interface Usage –Channel Setup –Multicast Support  Opens  Summary

3 TCP/IP TML Overview  Reliability: TCP/IP as transport provides reliability  Congestion Control: TCP/IP as transport provides congestion control  Security: Use of TLS provides desired security  Addressing: –Unicast: standard use of TCP/IP channels –Multicast: simulated over unicast channels

4 TCP/IP TML Overview (contd.)  Prioritization: –Scheduling within TML over a channel –Use of separate data and control channels  Encapsulations: Propose use of a TML header for PL messages and messages it generates [requirement for a TML header under investigation]  High Availability: –TML Heartbeats [under investigation, may not be required if PL heartbeat exists] –Channels setup between active and standby CEs to an FE  Protection (Mitigation) Against DoS Attacks: –Separation of data and control messaging via use of separate channels –Prioritization of control messages

5 CE-FE Communication Channels CE TML (Server) FE TML (Client) TCP Control Channel (Cc) TCP Data Channel (Cd) FE PL FE TML (Client) FE PL FE TML (Client) FE PL CE PL TCP Control Channel TCP Data Channel FE 1 FE 2 FE N

6 CE-FE Communication Channels (contd.)  Separate control and data channels  CE listens for channel setup by FE on well- defined (server) port  Channel setup initiated by FE (client)  Channel shutdown may be initiated by either CE or FE  Control and data channels between each CE (active/standby) and each FE  Prioritization of messages over the channels

7 Unicast and Multicast Messaging  Unicast and multicast messaging supported over unicast communication channels  Simulated Multicast Support: –Multicast join/leave messages sent over control channel [under investigation: model may change from receiver initiated to CE configured] –Using multiple unicast channels  Mimic behavior of Traditional Multicast: –Multicast group information obtained through configuration –Receiver initiated multicast tree setup [under investigation: model may change from receiver initiated to CE configured] –CE: root/source of multicast tree –FE: leaf/receiver of multicast tree

8 Unicast and Multicast Messaging  Unicast versus multicast message distinguished via the channel/group descriptor used when sending message

9 TML Messaging  TML transports: –PL control messages –PL data messages –TML control messages [under investigation if any control messages are required – may be transported over a separate TML control channel]  Minimal/Shim TML Header used for de-multiplexing messages [under investigation if TML header is required] –Flag: Protocol flag for de-muxing PL/TML messages –Version: TML Version –Message Type: Different TML Messages (e.g. Join/Leave) –Message length: Length of TML message only (not of entire payload)

10 TML Service Interface  Provides a service interface to an upper layer protocol (PL)  Support for: –Channel setup and shutdown –Multicast group join and leave –Write/send message (unicast or multicast) –Read/receive message

11 TML Service Interface (contd.)  tmlInit: Enable establishment of channels. [CE]  tmlOpen: Set up a unicast channel. [FE]  tmlClose: Shut down a unicast channel. [CE or FE]  tmlWrite: Send a message over a channel. [CE or FE]  tmlRead: Read a message over a channel. [CE or FE]  tmlMulticastGroupJoin: Join a multicast group. [FE]  tmlMulticastGroupLeave: Leave a multicast group joined previously. [FE]

12 TML Service Interface Usage: Channel Setup FE PLFE TMLCE TMLCE PL tmlInit (Cc) tmlInit (Cd) tmlOpen(Cc) TCP ctrl chan (Cc) setup CcDes Association, capability, topology info Setup control channel Setup data channel CE init/ boot up STEADY STATE OPERATION tmlEvent (CcUp) CcDes tmlEvent (CcUp) tmlOpen(Cd) TCP data chan (Cd) setup CdDes tmlEvent (CdUp) CdDes tmlEvent (CdUp) tmlWrite (CcDes) tmlRead(CcDes)

13 TML Service Interface Usage: Multicast Support [under investigation] FE1 PLFE1 TMLCE TMLCE PL tmlMcGrpJoin Multicast group join Join multicast group STEADY STATE OPERATION Join upcall Grp X = {FE1} Join ok tmlWrite (X) Write to McGrp X  msg sent to FE1 only FE2 PLFE2 TMLCE TMLCE PL tmlMcGrpJoin Multicast group join Join multicast group Join upcall Grp X = {FE1, FE2} Join ok tmlWrite (X) Write to McGrp X  msg sent to FE1 and FE2 1 st join req. for McGrp. Create grp. 2 nd join req. for McGrp X. Update grp. members

14 TML Service Interface Usage: Multicast Support (contd.) [under investigation] FE2 PLFE2 TMLCE TMLCE PL tmlMcGrpLeave Multicast group leave Leave multicast group STEADY STATE OPERATION Leave upcall Grp X = {FE1} Leave ok tmlWrite (X) Write to McGrp X  msg sent to FE1 only Update grp. members

15 Opens/Under investigation  Broadcast messaging model  Detailed High Availability model  Details on message prioritization  TML Messaging/Encapsulations: Are TML control messages required?  Multicast Model: Receiver initiated versus CE configured

16 Summary  TCP/IP based TML for ForCES protocol: –TCP/IP is widely deployed and meets TML requirements  Provides a Service Interface for PL  Areas missing in previous draft that have been addressed in this version: –Connection setup –Uni/Multicast support –TML messaging/encapsulations –Service Interface  Request: “TCP/IP based TML for ForCES Protocol” be made a Working Group draft

17 Backup

18 Problem Statement  Requirements RFC 3654 – “Protection against Denial of Service Attacks (based on CPU overload or queue overflow) - Systems utilizing the ForCES protocol can be attacked using denial of service attacks based on CPU overload or queue overflow. The ForCES protocol could be exploited by such attacks to cause the CE to become unable to control the FE or appropriately communicate with other routers and systems. The ForCES protocol MUST therefore provide mechanisms for controlling FE capabilities that can be used to protect against such attacks. FE capabilities that MUST be manipulated via ForCES include the ability to install classifiers and filters to detect and drop attack packets, as well as to be able to install rate limiters that limit the rate of packets which appear to be valid but may be part of an attack (e.g., bogus BGP packets).”

19 Possible Solutions  Basic Idea – Separation of data and control messages –Data messages are control protocol packets such as RIP, OSPF, BGP packets. All other messages considered control messages  Solution 1 – Different Transport connections –Use different congestion aware transport protocol connections for data and control messages  Solution 2 – Different Prioritization –Assign higher priority to control messages and use scheduling mechanisms in protocol to differentiate

20 Experimental Setup  Used IXIA box as packet generator and Linux PCs as CE, FE connected using 100 Mbps Ethernet links  Basic implementation consisting of multi-threaded client/server on Linux using pthreads (RR scheduling for threads)  Increased data connection rate to simulate DoS Attack

21 Experimental Results  Using TCP for control and UDP for data messages (with and without prioritization for control)  Results show UDP (data) overwhelms TCP (control) traffic during DoS attack, prioritization of No help  With Prioritization

22 Experimental Results (contd..)  Using TCP for control and TCP for data messages (with and without prioritization for control  Results show control traffic is not overwhelmed by data traffic during DoS attack, prioritization helps improve the performance (by 5%)  With Prioritization

23 Protocol for Data Channel  May need further investigation  Other options: –Datagram Congestion Control Protocol (DCCP) –Provides congestion control but not reliable (which satisfies requirements for data channel) –Experimented with this but no stable implementation available at this point –Generic Routing Encapsulation (GRE) Tunneling –Encapsulate data packets in a GRE header  data channel is a GRE tunnel –Rate limiting may be done by the FE to provide support for congestion control –Consider other tunneling protocols