1 / 11

Robert Hancock, Henning Schulzrinne (editors) IETF#64 – Vancouver November 2005

GIST – The NSIS Transport Layer draft-ietf-nsis-ntlp-08.txt Slides: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-08.ppt. Robert Hancock, Henning Schulzrinne (editors) IETF#64 – Vancouver November 2005. Status. Version -08 released 27 th September

linh
Download Presentation

Robert Hancock, Henning Schulzrinne (editors) IETF#64 – Vancouver November 2005

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. GIST – The NSIS Transport Layerdraft-ietf-nsis-ntlp-08.txtSlides: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-08.ppt Robert Hancock, Henning Schulzrinne (editors) IETF#64 – Vancouver November 2005

  2. Status • Version -08 released 27th September • Taking account of interop results, Paris discussions • WGLC began 3rd October, now (officially) complete • Comments from Jia Jia, Thomas Herzog, Nary Tra, Georgios Karagiannis, Mayi Zoumaro Djayoon, Martijn Swanink, Roland Bless, Martin Stiemerling, Pasi Eronen, Hannes Tschofenig, Xiaming Fu, Christian Dickmann, John Loughney, Andrew McDonald • Involving people from 5+ implementation activities • Version -09 ‘in progress’ • These slides are “what’s being done for version -09”

  3. MA Hold Time Negotiation • GIST-Confirm doesn’t include the MA-Hold-Time • So, a node which holds no state until the handshake completes doesn’t know what hold time to use • Solution: Add abbreviated SCD to confirm

  4. TLS Usage (1/2) • (From discussion of Pasi & Hannes’ ‘Securing GIST’ draft) • Current text on TLS 1.0/1.1 can stand • Helpful to be more prescriptive about TLS application profile (cipher suites etc.) • Can use Diameter base as example text

  5. TLS Usage (2/2) • Several ways of using TLS require more ‘out of band’ configuration before the handshake starts • Essentially, choosing which credentials to use and verify • Related: choosing which type of handshake to carry out • How to carry this data at the GIST level? • Declare that credentials should be tied to the Peer-Identity field (NLI object) • May need to define the format for this field more precisely • Define option data format for TLS in SCD object • Or, consider these ‘advanced TLS’ uses as a GIST extension (keep current TLS as ‘basic’ option)

  6. Downgrade Attacks Querying Node Responding Node • Current mechanism is to repeat Stack-Proposal over the messaging association • This can then be verified at the Responder • Need more description of what attacks this does/does not prevent • In particular, dependence on policy about what to offer, different strengths of what can be offered • To answer question ‘is the echoed Stack-Proposal-R actually useful’ GIST-Query: Stack-Proposal-Q(fixed for interface and NSLPID)Stack-Configuration-Data-Q(parameters for possible protocols) GIST-Response: Stack-Proposal-R(fixed for interface and NSLPID)Stack-Configuration-Data-R(parameters for possible protocols) GIST-Confirm (in C-mode): Stack-Proposal-R (echoed)

  7. Message Association Merging • (Arose out of discussion of the ‘GIST over SCTP’ draft) • When nodes form adjacencies over multiple interfaces, can get multiple MAs • Occurs e.g. when you have policy routing or load splitting between peers • Now have to keep all the MAs (no ‘merging’) • (This is a simplification)

  8. Cookie Liveness • Liveness data in R-cookie can be used to pre-filter Confirm messages • 2-stage cookie validation: is it live; does it pass hash validation • Improved resistance to blind attacks • Added text in security considerations on ‘good’ ways to include the liveness data to support this

  9. Adjacency Setup Clarifications • Clarifying the sequence of events that takes place when a node receiving a Query decides whether to form an adjacency or drop out of the signalling path • Mainly relates to API description and message processing rules in section 6 • Also wrap up clarification on what to do with piggybacked data carried in handshake messages

  10. Not sure about … • Need for text describing internal timer operation and setting • E.g. how to manage the timer that controls the generation of routing state refresh messages • Spec currently just defines when state expires • Up to the implementor to generate a message appropriately in advance, with jitter etc.

  11. Minor Technical Fixes/Clarifications • Order of protocols in a stack profile • Now defined as top-to-bottom • Rules about Query retransmission apply to all Queries • Stateless nodes can accept Data • SetStateLifetime includes the NSLPID • R flag controls whether to send a Confirm

More Related