slide1 n.
Skip this Video
Download Presentation
Robert Hancock, Henning Schulzrinne (editors) IETF#64 – Vancouver November 2005

Loading in 2 Seconds...

play fullscreen
1 / 11

Robert Hancock, Henning Schulzrinne (editors) IETF#64 – Vancouver November 2005 - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Robert Hancock, Henning Schulzrinne (editors) IETF#64 – Vancouver November 2005' - linh

Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

GIST – The NSIS Transport Layerdraft-ietf-nsis-ntlp-08.txtSlides:

Robert Hancock, Henning Schulzrinne (editors)

IETF#64 – Vancouver

November 2005

  • 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”
ma hold time negotiation
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
tls usage 1 2
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
tls usage 2 2
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)
downgrade attacks
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)

message association merging
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)
cookie liveness
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
adjacency setup clarifications
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
not sure about
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.
minor technical fixes clarifications
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