NECP: the Network Element Control Protocol IETF WREC Working Group November 11, 1999

where is NECP needed? ISP User Network Servers (Origin Servers, Proxy Caches, etc.) Router L4 Switch (load balancing, or intercepting for transparent proxies) Note that a Server usually knows what it wants, but the Switch is feeding it the packets Internet (Large Backbone ISP)

the role of NECP Servers (load balanced groups, transparent proxies) L4 Switch NECP allows the cache and switch to exchange control traffic

what control traffic? When servers come up, they can tell the switch: “add me to your group for Service X” Servers can send load information; switch does better balancing Switches immediately stop sending work to dead servers using periodic KEEPALIVEs Transparent Proxy Caches can tell switches to allow direct connections for certain clients (e.g., on auth failure)

key features Specific load balancing policies IP addresses of friendly servers/caches Configuration management Minimal Assumes per-flow state available on switch Extensible load metrics Authentication non-features

Backup Slides

udp (or snmp): why not use it? Initially, SNMP seemed perfect to us -- it’s a generic way for net devices to interoperate But, we found ourselves redesigning things that were already in TCP. We use TCP’s: –stream demultiplexing –retransmission policy –segmentation & reassembly of large messages –flow control –congestion control Like BGP, or ICP

NAT and GRE Earlier versions of the protocol include complex NAT queries in case the original IP dest addr was lost. Why not encapsulate? Generic Routing Encapsulation to tunnel application packets from proxy to cache Now - no NAT problems; reduces complexity of design and implementation

authentication Both sides share a secret (say, a password) Sender: –appends the secret to its message –calculates an SHA-1 hash –replaces the secret with the SHA-1 Receiver: –Saves the SHA-1 –Replaces the SHA-1 with the secret –Calculates the SHA-1 (should match) Sequence numbers to prevent replay attacks Note: this is authentication, not encryption

redirection semantics If a server asks a switch to change its forwarding state (e.g., stop forwarding a dest port number), do existing flows break? –Do we add a “stop giving me dest port X, except for the following ethereal ports” command? (Complex; doesn’t work for start) –Ostrich Algorithm: let the connections break? – Do we assume that all switches keep per-flow state, and can redirect new connections without breaking old ones?