IRIS and Application Transports Andrew Newton CRISP Working Group 58 th IETF, Minneapolis, MN, USA November 12, 2003

BEEP ● IRIS currently specifies BEEP/TCP (RFC 3080/3081) as the “default” transport. – Provides ● Framing, security framework, versioning, and much more... ● The “full-service” application transport. – Explicitly specified by “iris.beep” URI scheme ● Implicit for “iris” URI scheme as the fallback. ● This presentation is NOT about replacing BEEP.

The Open Door ● Are we allowed to discuss other transports? ● From our requirements: – “The protocol MUST define one or more congestion-aware transport mechanisms for mandatory implementation.”

IRIS Transport Design ● Iris-core specifically leaves room for more transports: – Nothing in or above the IRIS layer is “stateful” ● Session state related to authentication/authorization is purposefully assigned to the application transport layer – Uses S-NAPTR – Specifies how to map additional URI schemes – Etc...

A Survey of Possible Transports ● Fast and Light UDP – Straight XML (iris-lwx) – GZIP compressed (iris-lwz) – Tokenized XML (iris-lwb) ● Simple TCP-based – Straight XML (iris-tcp) – Secured with SSL/TLS (iris-tls) ● HTTP-based – Layered directly on HTTP (iris-http) – SOAP (iris-soap)

Fast and Light UDP ● Fast and Light ● But... – Does not lend itself towards long messages – Not good for stateful transactions (authorization) – No encryption/confidentiality/other security goodies ● However, perfect for situations where no authentication is needed (anonymous access) and results are small.

IRIS-LWZ ● Compressed XML over UDP – XML -> GZIP -> UDP – Defines a simple XML wrapper ● Profiles (similar to BEEP mechanism) ● Client-specified UDP datagram sizes ● See draft-newton-iris-lightweight

A Sample IRIS-LWZ Request <lwzRequest ● xmlns="urn:ietf:params:xml:ns:iris-lwz" ● xmlns:xsi=" ● serverName="com" length="1280"> ● ● <dreg:findDomainsByContact ● xmlns:dreg="urn:ietf:params:xml:ns:dreg1"> ● com ● ● The Cobbler Shoppe ● ● registrant ●

A Sample IRIS-LWZ Response <lwzResponse ● xmlns="urn:ietf:params:xml:ns:iris-lwz" ● xmlns:xsi=" ● ● <domain ● xmlns="urn:ietf:params:xml:ns:dreg1" ● authority="com" registryType="dreg1" ● entityClass="domain-handle" entityName="tcs-com-1" > ● thecobblershoppe.com ●

IRIS-LWX & IRIS-LWB ● IRIS-LWX – Similar idea to IRIS-LWZ – XML -> UDP ● IRIS-LWB – Instead of compression, XML is tokenized with WBXML. – XML Data -> WBXML -> UDP – WBXML can be faster than straight XML ● But not namespace aware – simple wrapper may get bigger

Simple TCP-based Transports ● Straight layering of IRIS over TCP – XML -> TCP – Simple wrapping similar to iris-lwz – Will remind us of port 43 ● Straight layering of IRIS over SSL/TLS – XML -> TLS -> TCP – The same as above, except inserts TLS ● But no protocol advantages over BEEP

HTTP-based ● Issues with BCP 56 ● Direct Layering over HTTP (iris-http) – Sounds simple but it is not ● Using SOAP (iris-soap) – Technically not an app-transport – Issues with session semantics – But seemingly very popular ● No protocol advantages over BEEP

The Case for UDP ● Advantages over BEEP when: – Access is anonymous – Result set can be squeezed into 512 to 1500 bytes ● Do we have these situations today? – 95% of queries against whois.verisign-grs.com – 80% of queries against whois.arin.net – 80% of queries against whois.ripe.net – Average answer size of non-recursive answers for whois.nic.de is 1199 bytes

The Case for UDP ● Need for very fast domain name check – Many registries are deploying/planning deployment of very fast domain name check service – IRIS over UDP would be perfect for this ● Either using 'dreg' ● Or with a scaled-down version of 'dreg' like 'dchk'