GIST%20

1
GIST The NSIS Transport Layerdraft-ietf-nsis-nt
lp-08.txt Slides http//nsis.srmr.co.uk/reh/dra
ft-ietf-nsis-ntlp-08.ppt

• Robert Hancock, Henning Schulzrinne (editors)
• IETF64 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 whats being done for version
  -09

3
MA Hold Time Negotiation

• GIST-Confirm doesnt include the MA-Hold-Time
• So, a node which holds no state until the
  handshake completes doesnt 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