TRIGTRAN Strawperson Framework draft-dawkins-trigtran-framework-00.txt Spencer Dawkins spencer_dawkins@yahoo.com Carl E. Williams carlw@mcsr-labs.org Alper E. Yegin Alper@docomolabs-usa.com IETF-56 San Francisco 1 3/20/2003
So, you already have a Framework? • No. • We’re exploring an approach • … because we’re looking for fatal flaws • … like “can we actually generate triggers?” • … and “can we actually send them?” • This approach helped us ask these questions • … but “Connectivity Restored” doesn’t need it • … so Framework should be on hold for now IETF-56 San Francisco 2 3/20/2003
Framework Basics • Accommodate multiple transports – Focus on TCP, don’t break SCTP – others? • Initiator/Correspondent model – Focus on access links – Focus on single-homed Initiators • Protocol flow • Canonical triggers? • Canonical responses? • Notification protocol mechanisms? • Canonical security considerations? IETF-56 San Francisco 3 3/20/2003
Minimal TRIGTRAN Architecture TRIGTRAN Correspondent Initiator HOST HOST TRIGTRAN Router Subnetwork Subnetwork Of Interest Of Interest IETF-56 San Francisco 4 3/20/2003
Minimal TRIGTRAN Functionality Subnetwork Event Subnetwork Event TRIGTRAN Correspondent Initiator HOST HOST TRIGTRAN Router Transport IP Layer Subnetwork Layer Subnetwork Subnetwork Notify Transport Notify Transport Event Here Event Here Here Here IETF-56 San Francisco 5 3/20/2003
Focus on Access Links • Many problematic links are access links • Can’t guarantee core routers see all packets • Core network will reroute anyway • Avoid core network scaling problem • Access network may have incentive to deploy • Core network does not have this incentive IETF-56 San Francisco 6 3/20/2003
Focus on Single-homed Initiators • Maps to one class of problematic subnetworks – Wide-Area Wireless Networks • Avoid “fan-in” problem at correspondent host • Unambiguous notifications are most valuable • New interface -> new bandwidth anyway IETF-56 San Francisco 7 3/20/2003
Protocol Flow - Initiation TRIGTRAN Correspondent Initiator HOST HOST TRIGTRAN Router Arbitrary packet Arbitrary packet with TRIGTRAN with TRIGTRAN Initiate bit set Initiate bit set IETF-56 San Francisco 8 3/20/2003
Router Action - Initiation TRIGTRAN TRIGTRAN router TRIGTRAN router Correspondent Initiator may install/update may install/update HOST HOST partial soft state at partial soft state at this point this point TRIGTRAN Router Arbitrary packet Arbitrary packet with TRIGTRAN with TRIGTRAN Initiate bit set Initiate bit set IETF-56 San Francisco 9 3/20/2003
Protocol Flow - Request TRIGTRAN Correspondent Initiator HOST HOST TRIGTRAN Router Arbitrary packet Arbitrary packet with TRIGTRAN with TRIGTRAN Initiate and Request bits set Initiate and Request bits set IETF-56 San Francisco 10 3/20/2003
Router Action – Request TRIGTRAN TRIGTRAN router TRIGTRAN router Correspondent Initiator must install/update must install/update HOST HOST soft state at this soft state at this point point TRIGTRAN Router Arbitrary packet Arbitrary packet with TRIGTRAN with TRIGTRAN Initiate and Request bits set Initiate and Request bits set IETF-56 San Francisco 11 3/20/2003
Protocol Flow - Notification Subnetwork Event Subnetwork Event TRIGTRAN Correspondent Initiator HOST HOST TRIGTRAN Router TRIGTRAN Notification TRIGTRAN Notification from router to Correspondent Host from router to Correspondent Host IETF-56 San Francisco 12 3/20/2003
Router Action - Notification Subnetwork Event Subnetwork Event TRIGTRAN TRIGTRAN router TRIGTRAN router Correspondent Initiator detects Subnetwork detects Subnetwork HOST HOST event for an active event for an active Initiator Host Initiator Host TRIGTRAN router TRIGTRAN router TRIGTRAN sends Notification to sends Notification to Router Correspondent Host Correspondent Host TRIGTRAN Notification TRIGTRAN Notification from router to Correspondent Host from router to Correspondent Host IETF-56 San Francisco 13 3/20/2003
Canonical Triggers? • One proposal for minimal set of events: – Connectivity Interrupted – Connectivity Restored – Packets Discarded by subnetwork, not due to congestion • More ambitious (“research”) events: – Sub-network path changes (“horizontal handoff”) – Packet corruption loss – Non-congestion loss – Nominal sub-network bandwidth change • Current Framework does not include “ambitious” events IETF-56 San Francisco 14 3/20/2003
Notification Protocol Mechanisms? • We’re dealing with a huge issue here • ICMP message is right answer conceptually – A less ambiguous/more flexible Source Quench? • But is it deployable? – Old implementations, NATs, Firewalls, etc. • Is a new UDP message likely to be better? • DCCP flows too heavyweight? – Number of flows for an access router? – Not a connection, but still need per-flow state • TCP is right for end-to-end TCP Kickstart… IETF-56 San Francisco 15 3/20/2003
Canonical Security Considerations? • Non-starter – Assume security association between TRIGTRAN access router and arbitrary correspondent host somewhere on the Internet • First attempt at solving this problem – Limit TRIGTRAN to advisory role – If you have notifications and ACKs, believe ACKs! – No new transport behavior • Alternative choice? – Explore Purpose-Built Keys framework – No identity component – only spoof-resistance – MIGHT allow different different class of responses IETF-56 San Francisco 16 3/20/2003
Canonical DOS Considerations? • Assuming strawperson security considerations proposal (advisory) • Clearing Initiate/Request bits not interesting – Gives current transport behavior • Setting Initiate/Request bits not very interesting – Requires attacker on both sides of router to install state in router Forged Connectivity Interrupted not interesting • – Believe end-to-end ACKs if they come • Forged Connectivity Restored not interesting – Probe once during Connectivity Interrupted, then normal loss processing • Forged Packets Discarded not interesting – Resend packets once during loss event, then normal loss processing DOS flooding of TRIGTRAN routers not interesting • – No worse than any Router Alert flooding attack – Reverts to current transport behavior during flooding attacks - but who cares? IETF-56 San Francisco 17 3/20/2003
Feedback in the halls so far • “Trigger” name still seems to give the wrong message • Need to be clear about timeframes – think “five years” • Out-of-band notifications are very problematic – ICMP blocks, UDP blocks, firewalls, NATs, ALGs, etc. • “Packets Discarded” ambiguous – looks like “handoff” • “Connectivity Interrupted” response isn’t clear – Transports that retry more persistently? Or give up sooner? • Even “Connectivity Restored” requires TCP change • Sending notifications all the time is simpler – No bits, no “initiator/requestor”, no decisions – And, if we’re headed for general deployment, maybe right idea • Need to be clear about topology aspects of DoS attacks IETF-56 San Francisco 18 3/20/2003
Kicking TCP Subnetwork Event Subnetwork Event Mobile Assume “Stationary Assume “Stationary Stationary HOST Host” is sender, and Host” is sender, and HOST has TCP has TCP connections in RTO connections in RTO Any Router Phil Karn Karn, “Kicking TCP”, March 2000 PILC list posting , “Kicking TCP”, March 2000 PILC list posting Phil IETF-56 San Francisco 19 3/20/2003
Kicking TCP Mobile When “Mobile When “Mobile Stationary HOST Host” sees interface Host” sees interface HOST go operational, go operational, resend last TCP resend last TCP packet on each TCP packet on each TCP connection connection Any Router Last TCP packet previously sent on this connection Last TCP packet previously sent on this connection IETF-56 San Francisco 20 3/20/2003
Kicking TCP Mobile When “Stationary When “Stationary Stationary HOST Host” sees duplicate Host” sees duplicate HOST TCP packet arrive TCP packet arrive for connection in for connection in RTO, behave as if RTO, behave as if RTO timer popped RTO timer popped Any and send single- and send single - Router packet probe packet probe Single- -packet probe on this connection packet probe on this connection Single IETF-56 San Francisco 21 3/20/2003
Kicking TCP Mobile When single- -packet packet When single Stationary HOST probe arrives, probe arrives, HOST “Mobile Host” “Mobile Host” sends sends Acknowledgement Acknowledgement Any Router Acknowledgement for Single- -packet probe on this connection packet probe on this connection Acknowledgement for Single IETF-56 San Francisco 22 3/20/2003
Kicking TCP Mobile When When Stationary HOST acknowledgement to acknowledgement to HOST single- -packet probe packet probe single arrives, “Stationary arrives, “Stationary Host” enters Slow Host” enters Slow Start Start Any Router Normal transmission resumes with ACK clocking Normal transmission resumes with ACK clocking IETF-56 San Francisco 23 3/20/2003
Recommend
More recommend
