1 / 12

Andrew Newton IETF ECRIT Working Group 1 February 2006 Washington, DC, US

Emergency Contacts (ECON) draft-hardie-ecrit-iris-03 Andrew Newton, VeriSign Ted Hardie, Qualcomm Hannes Tschofenig, Siemens. Andrew Newton IETF ECRIT Working Group 1 February 2006 Washington, DC, US. Background. Emergency Contact (ECON) is specified as an IRIS (RFC 3981) registry type.

oren-fitzgerald
Télécharger la présentation

Andrew Newton IETF ECRIT Working Group 1 February 2006 Washington, DC, US

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Emergency Contacts (ECON)draft-hardie-ecrit-iris-03Andrew Newton, VeriSignTed Hardie, QualcommHannes Tschofenig, Siemens Andrew Newton IETF ECRIT Working Group 1 February 2006 Washington, DC, US

  2. Background • Emergency Contact (ECON) is specified as an IRIS (RFC 3981) registry type. • A simple request/response protocol using XML. • Uses S-NAPTR (RFC 3958) • Profiled use of NAPTR and SRV • Distinguishes between App proto and Transfer Proto • Protocol preference can be stated. • Host/port preference can be stated. • IRIS was created in the CRISP working group by TLD operators. • Who know a thing or two about high resolution loads, operations of highly available services, and moving data around the globe.

  3. A Simple Request <request xmlns="urn:ietf:params:xml:ns:iris1"> <searchSet> <findEconByCivic xmlns="urn:ietf:params:xml:ns:econ1" > <civilAddress> <country>US</country> <A1>New York</A1> <A3>New York</A3> <A6>Broadway</A6> <HNO>123</HNO> <LOC>Suite 75</LOC> <PC>10027-0401</PC> </civilAddress> <serviceFunction>police</serviceFunction> </findEconByCivic> </searchSet> </request>

  4. A Simple Response <response xmlns="urn:ietf:params:xml:ns:iris1"> <resultSet> <answer> <emergencyContact xmlns="urn:ietf:params:xml:ns:econ1" authority="example.com" registryType="econ1" entityClass="econ" entityName="nypd" > <displayName> New York City Police Department </displayName> <serviceFunction>police</serviceFunction> <uri> sip:nypd@example.com xmpp:nypd@example.com </uri> </emergencyContact> </answer> </resultSet> </response>

  5. Caching • Caching of answers by “seekers”. • In the case of civic addresses… • If your civic address does not change within X number of minutes, do not requery. • In the case of geo… • If your coordinates stay within polygon Y for X number of minutes, do not requery.

  6. Database Replication in ECON • We take no single position on database replication with ECON. • It most likely will differ greatly throughout the world. • Isn’t it out of scope? • But we have identified 3 methods of conducting database replication with ECON. • Serialized database entries to a file as specified in IRIS. • And the file transfer protocol of your choice. Many people like SFTP. • ECONREP (ECON Replication) • Interactive IRIS profile. • Replication of entries before they become active. • Incremental replication. • Anything you find that works better for your situation. • RDBMS replication • Shared Network Memory • Osmosis, crystal balls, and strong hope

  7. Object Signing Considered Harmful • My house is on fire. Who do I call? • Please update your client with the proper trust anchors. • My house is still on fire. • Please cryptographically verify these URIs. • It’s getting hotter. • Please check this CRL. • Did I mention that my house is on fire? • Object signing is useful for diagnosing problems. • But that happens after the incident, not during. • All the mechanisms to get object signing to work seem to be a pretty heavy price to pay for a diagnostic tool. • Due to the nature of ECRIT, will need to be “on-the-fly”. • VERY CPU INTENSIVE

  8. Comparison to DNS SOS and LUMP • DNS SOS • Similar in that it is built for speed by trying to utilize UDP when possible. • Unlike in that its query framework is not intertwined with its octet framing. • IRIS/ECON uses XML, which is much more flexible. • LUMP • Similar in that is just as flexible in the query framework. • Unlike in that it does not require heavyweight transfer protocol interactions used by SOAP/HTTPS. • IRIS/ECON uses UDP when possible to gain efficiencies and takes into careful consideration the copious use of security mechanisms which may weigh down the protocol.

  9. Tell me about example.com Here is the data Packets in a Simple UDP Transaction Client Server

  10. { Open a TCP connection Connection induced state. Consumes memory, ports, and CPU in the server. { Are you Sure? Yes. I need some data. NOTE: At this point 3 packets have been exchanged, but no data has been exchanged. Here is the data Thanks. Close the TCP connection Ok. Packets in a typical TCP Transaction Client Server

  11. Open a TCP connection TLS( ClientHello). TLS( Certificate ). TLS( ServerHello). Are you Sure? Yes. TLS( ServerHelloDone ). TLS( ChangeCipherSpec ). TLS( ClientKeyExchange ). I need some data. { Here is the data TLS( Finished ). Thanks. This is where ECRIT data starts to be exchanged. TLS( ChangeCipherSpec ). TLS( Finished ). Close the TCP connection TLS( ClosureAlert ). TLS( ClosureAlert ). Ok. Messages in a typical TLS Transaction Client Server

  12. UDP vs. TCP vs. TLS • IRIS queries over UDP, TCP, and TLS. • 5 distinct queries X 500 iterations • = 2,500 queries • UDP • 13.8 X faster than TCP • 45.9 X faster than TLS • TCP • 3.4 X faster than TLS

More Related