TRIGTRAN Strawperson Framework - - PowerPoint PPT Presentation

IETF-56 San Francisco 3/20/2003 1

Spencer Dawkins spencer_dawkins@yahoo.com Carl E. Williams carlw@mcsr-labs.org Alper E. Yegin Alper@docomolabs-usa.com

TRIGTRAN Strawperson Framework

draft-dawkins-trigtran-framework-00.txt

IETF-56 San Francisco 3/20/2003 2

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 3/20/2003 3

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/20/2003 4

Minimal TRIGTRAN Architecture

TRIGTRAN Initiator HOST TRIGTRAN Router Correspondent HOST

Subnetwork Subnetwork Of Interest Of Interest

IETF-56 San Francisco 3/20/2003 5

Minimal TRIGTRAN Functionality

TRIGTRAN Initiator HOST TRIGTRAN Router Correspondent HOST

Subnetwork Layer IP Layer Transport

Notify Transport Notify Transport Here Here

Subnetwork Subnetwork Event Here Event Here

Subnetwork Event Subnetwork Event

IETF-56 San Francisco 3/20/2003 6

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 3/20/2003 7

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 3/20/2003 8

Protocol Flow - Initiation

TRIGTRAN Initiator HOST TRIGTRAN Router Correspondent HOST

Arbitrary packet Arbitrary packet with TRIGTRAN with TRIGTRAN Initiate bit set Initiate bit set

IETF-56 San Francisco 3/20/2003 9

Router Action - Initiation

TRIGTRAN Initiator HOST TRIGTRAN Router Correspondent HOST

Arbitrary packet Arbitrary packet with TRIGTRAN with TRIGTRAN Initiate bit set Initiate bit set

TRIGTRAN router TRIGTRAN router may install/update may install/update partial soft state at partial soft state at this point this point

IETF-56 San Francisco 3/20/2003 10

Protocol Flow - Request

TRIGTRAN Initiator HOST TRIGTRAN Router Correspondent HOST

Arbitrary packet Arbitrary packet with TRIGTRAN with TRIGTRAN Initiate and Request bits set Initiate and Request bits set

IETF-56 San Francisco 3/20/2003 11

Router Action – Request

TRIGTRAN Initiator HOST TRIGTRAN Router Correspondent HOST

Arbitrary packet Arbitrary packet with TRIGTRAN with TRIGTRAN Initiate and Request bits set Initiate and Request bits set

TRIGTRAN router TRIGTRAN router must install/update must install/update soft state at this soft state at this point point

IETF-56 San Francisco 3/20/2003 12

Protocol Flow - Notification

TRIGTRAN Initiator HOST TRIGTRAN Router Correspondent HOST

TRIGTRAN Notification TRIGTRAN Notification from router to Correspondent Host from router to Correspondent Host

Subnetwork Event Subnetwork Event

IETF-56 San Francisco 3/20/2003 13

Router Action - Notification

TRIGTRAN Initiator HOST TRIGTRAN Router Correspondent HOST

TRIGTRAN Notification TRIGTRAN Notification from router to Correspondent Host from router to Correspondent Host

TRIGTRAN router TRIGTRAN router detects Subnetwork detects Subnetwork event for an active event for an active Initiator Host Initiator Host TRIGTRAN router TRIGTRAN router sends Notification to sends Notification to Correspondent Host Correspondent Host

Subnetwork Event Subnetwork Event

IETF-56 San Francisco 3/20/2003 14

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 3/20/2003 15

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 3/20/2003 16

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 3/20/2003 17

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 3/20/2003 18

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 3/20/2003 19

Kicking TCP

Mobile HOST Any Router Stationary HOST Assume “Stationary Assume “Stationary Host” is sender, and Host” is sender, and has TCP has TCP connections in RTO connections in RTO

Subnetwork Event Subnetwork Event

Phil Phil Karn Karn, “Kicking TCP”, March 2000 PILC list posting , “Kicking TCP”, March 2000 PILC list posting

IETF-56 San Francisco 3/20/2003 20

Kicking TCP

Mobile HOST Any Router Stationary HOST When “Mobile When “Mobile Host” sees interface Host” sees interface go operational, go operational, resend last TCP resend last TCP packet on each TCP packet on each TCP connection connection

Last TCP packet previously sent on this connection Last TCP packet previously sent on this connection

IETF-56 San Francisco 3/20/2003 21

Kicking TCP

Mobile HOST Any Router Stationary HOST When “Stationary When “Stationary Host” sees duplicate Host” sees duplicate 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 and send single and send single-

• packet probe

packet probe

Single Single-

• packet probe on this connection

packet probe on this connection

IETF-56 San Francisco 3/20/2003 22

Kicking TCP

Mobile HOST Any Router Stationary HOST When single When single-

• packet

packet probe arrives, probe arrives, “Mobile Host” “Mobile Host” sends sends Acknowledgement Acknowledgement

Acknowledgement for Single Acknowledgement for Single-

• packet probe on this connection

packet probe on this connection

IETF-56 San Francisco 3/20/2003 23

Kicking TCP

Mobile HOST Any Router Stationary HOST When When acknowledgement to acknowledgement to single single-

• packet probe

packet probe arrives, “Stationary arrives, “Stationary Host” enters Slow Host” enters Slow Start Start

Normal transmission resumes with ACK clocking Normal transmission resumes with ACK clocking

IETF-56 San Francisco 3/20/2003 24

If We Really “Kick TCP”

• Need a small change to TCP for duplicate packets

received on RTO connections

• Don’t need modifications to routers
• No router per-connection state
• “Last packet”goes anywhere TCP was going

– No (more) NAT, firewall, ALG considerations

• Safe (no response to probe is no-op)
• Recovers RTOed TCP sooner

– Could be up to 30 seconds sooner, with a human in the loop

• Need to define similar facility for other transports?
• Can’t reuse this mechanism for any other trigger

– Likely would require explicit notification, maybe edge-to-end