Docstoc

NSIS Framework Issues

Document Sample
NSIS Framework Issues Powered By Docstoc
					         NSIS Transport Layer
            draft-ietf-nsis-ntlp-01.txt
   Slides: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-01.ppt



Robert Hancock, Henning Schulzrinne (editors)
                 IETF#59 – Seoul
                   March 2004
                        Overview
   Status
       Structure basically unchanged since –00
       Some significant changes, some more detail
       Nearly implementable in a benign environment
   Changes and Open Issues
       Intermediaries/Topology/Layer Binding
       More explanation/detail/simplifications
       Route change handling
       Security analysis and documentation
       Everything else from Section 8
   What next…
         Intermediaries / Topology /
               Layer Binding
   -00 considered allowing intermediate nodes
    within a session
       To process an NSLP subset or go through NATs
       Handled by tunnelled C-mode encapsulations
   -01 avoid/prohibits these cases
       Split-level NSLP: must use >1 signalling sessions
       If NATs are handled in GIMPS, wrap this up with the
        route discovery process
       Route recording functionality disappears
                 Further Issues
   Should we tighten the rules: require NSLP
    peers be 1 GIMPS hop apart
       GIMPS and NSLP topologies are ‘conformant’
       Spec. allows this but does not enforce it
       Some security and routing implications
   How actually do to NAT traversal
       Requirements depend on deployment
       Need to work with NATFW people
       NSIS-unaware NAT case is especially hard
                    Messaging Details
   Worked example in 3.3
       Already stimulated some interesting clarifications
   Decoupled state management for routing and
    messaging
   Fragmentation restricted to reliable transports
       Can’t do it with UDP/DCCP
   Strawman message formats added
       5.1, 5.2, Appendix C
       Probably many open issues here
            Addressing flexibility, optional or mandatory fields, level of
             wildcarding …
             Route Change Handling
   Still following FW assumption: “Anyone can
    hint; NTLP detects; NSLP repairs”
   Details relate to:
       What is detected (and at which node)
       At what node notifications are delivered
   Document contains strawman proposal
       Needs review by NSLP people
            “Is this what is useful?”
       Needs review by mobility people (compatibility)
                          Security
   Basic picture of how GIMPS provides security for
    itself is clear
       Basically handling routing state integrity and DoS
        prevention
   Architectural open issues remain:
       Whether to allow NSLP to bind to GIMPS security
       How to analyse joint security of NSLP & GIMPS
       How to capture security protocol ‘profiles’ for different
        environments
   Basically 3 sides of the same coin
       Need face time here to work out how to proceed
                Other Open Issues
   See Section 8!
          8.1 Protocol Naming
          8.2 General IP Layer Issues
          8.3 Encapsulation and Addressing for Datagram Mode
          8.4 Intermediate Node Bypass and Router Alert Values
          8.5 Messaging Association Flexibility
          8.6 Messaging Association Setup Message Sequences
          8.7 GIMPS State Teardown
          8.8 Datagram Mode Retries & Single Shot Message Support
          8.9 GIMPS Support for Message Scoping
          8.10 Mandatory or Optional Reverse Routing State
          8.11 Additional Discovery Mechanisms
          8.12 Alternative Message Routing Requirements
          8.13 Congestion Control in Datagram Mode
The End
          Backup Slides

   Old Design Approach pictures
      (from –00 presentation)
1 slide on each official ‘open issue’
  from section 8 of the –01 draft
                  Design Approach (1/4)
   Various ways to get required additional
    functionality into 2205-like approach
   Currently: build a new messaging framework
    which incorporates 2205 functions and existing
    transport/security protocols
                                                               Signalling
    NSLP




                      Signalling
    level




                                             Signalling     Application - ANO
                   Application -QoS
                                       Application - midcom



                         GIMPS Message Encapsulation                            GIMPS State Maintenance                 GIMPS
     NTLP level




                   UDP          DCCP            SCTP             TCP                       Focus of specification
                                                                                                  is this

                                        Security
                                       Protocols                                 ...which includes management of all of this
                                      (TLS, IPsec)
     IP




                                           IP
         Design Approach (2/4)
   Message flows within a node:
            Design Approach (3/4)
   Routing state is                    Flow Direction


    set up as in 2205       Que rying
                             Node
                                                     Re sponding
                                                        Node
                                                                                       Use and setup of
                                                                                       messaging associations is

   When rtg. state                                                                    only weakly coupled to
                                                                                       routing state setup status


    exists, policy
                                         "GIMPS-query "
                              (Downstream datagram mode, UDP+RAO)



    dictates when                                                   Install upstream




                                                                                       Messaging associations can be used from here onwards
                                                                          state


    messaging
                                                                      (optimistic)




    associations are
                                        "GIMPS-response"




    set up and used
                            Install




                                                                                                           (if available)
                          downstream




                                                                                                                                              Messaging associations can be set
                                                                                                                                              up from here onwards (if desired)
                             state


       (and what sort,                  Final handshake

        and how many,
        and when they     Prompting and securing routing
                          state setup is controlled by the
                                                                    Install upstream
                                                                    state (cautious)


        are torn down     presence of special GIMPS
                          payloads
        again)
            Design Approach (4/4)
   Implications (among others):
    + Re-use existing transport/security technology
        + No ‘new’ protocol development
    + Additional functionality scales like #peers, not
      #flows/sessions
    0 Time/space overhead: little/no impact (given the
      functionality that is being achieved)
    - Nodes have to implement (non-trivial)
      transport/security protocols
        -   Processing at intermediaries gets harder
    -   Routing state maintenance stops being ‘free’
   ?
            8.1: Protocol Naming
   GIMPS (General Internet Messaging Protocol
    for Signaling)
   GIST (Generic Internet Signaling Transport)
   LUMPS (Lightweight Universal Messaging for
    Path associated Signaling)
   Other combinations of G/C, I, P, S, M, R, T,
    S (again)
       Remember Atlanta: NTLP is a stupid name and
        we promise not to use it for the real protocol
     8.2 General IP Layer Issues
   UDP or raw-IP
   Interception on protocol number (raw-IP)
    or assume RAO (either)
   Rely on UDP checksum or include our own
   Getting through NSIS-unaware NATs
   Implementation issues (can't easily do raw
    IP i/o, or can’t control TTLs via UDP)
   Aim for one choice?
           8.3 Encapsulation and
           Addressing for D-Mode
   Assume UDP (or raw-IP) only
       No DCCP, IPsec, …
   Flow sender or signalling sender as source
    address?
       Or implementation issue?
   Need a well-known port?
   Details on traffic class, flow label…
          8.4 Intermediate Node
          Bypass and RAO Values
   Assume interception on RAO present (and
    RAO value)
       Reality check?
   How to assign values to protect routers
    from high volumes of ‘irrelevant’ signalling
    messages?
   2+ aggregation options – need input
    requirements from NSLP work
       Cf. 3175 considerations (message rewriting)
        8.5 Messaging Association
               Flexibility
   How many to allow and how many
    different sorts?
       Many different possible stack configurations
       Policies for using different parallel associations
   Which should be the ‘MUST’ to implement?
       (decision needed eventually)
   Do we end up with another ISAKMP?
        8.6 Messaging Association
        Setup Message Sequences
   Allow the MA to be setup upstream as well
    as downstream?
   When to propagate the GIMPS-query
       Relative to other stages in the process
   When to propagate the MA setup
       Relative to other stages in the process
   Interactions between MA setup and
    discovery exchange
        8.7 GIMPS State Teardown
   Is this needed explicitly?
       What is the cost of leaving it up?
       How do you know when it is no longer needed?
            E.g. to send NSLP teardowns (more important)
            Potential race conditions in mobility scenarios
       RSVP comparison: what is the value of PATH TEAR?
   Is there any fate sharing between GIMPS and
    NSLP state?
     8.8 Datagram Mode ‘Transport’
   How to control retransmission in d-mode
       Needed if downstream message is lost
       Congestion issue
   Should it be extended to provide one-shot
    message transfer to NSLP?
       Or ‘c-mode or nothing’
   Congestion control in general (rate limits?)
           8.9 GIMPS Support for
              Message Scoping
   Which layer knows about network edges?
       Some applications need this
       Should it be a service provided by GIMPS?
   Rationale: it’s the GIMPS layer which has
    better access to clues about infrastructure
    configuration
       Aggregation boundaries, IP TTL, GHC…
        8.10 Mandatory or Optional
           Reverse Routing State
   Wanted by NSLPs which want to be lightweight
    in per-flow state requirements
   Not clear if this is done at protocol level…
       “don’t store reverse state for this message”
   … or at implementation/API level
       “I will never send reverse messages for that flow”
   May need to be added to datagram mode
    description
   Needs very careful analysis of error conditions
         8.11 Additional Discovery
               Mechanisms
   Should we consider other discovery
    mechanisms
       Compared to RAO+interception approach
   Examples
       Closer integration with routing protocols
       Configuration of topology constraints
       Can apply both to upstream and downstream
   Would require repeating the routing state
    integrity security analysis
         8.12 Alternative Message
          Routing Requirements
   Some additional desires for message
    routing
       Pre-installation on backup or predicted path
            May be out of scope now but providing it later
             probably shouldn’t break the protocol
       NATFW “inbound reservation” message
            Not clear if this can be disguised as a normal
             message
       Teardown on old path (QoS-NSLP SII issue)
            Can be done inside implementation if topology
             conformance is strictly enforced
        8.13 Congestion Control in
             Datagram Mode
   How?
       How conservative/how aggressive?
       Any way to use ECN?
            Needs more scenarios and analysis
   Current baseline assumption is that
    datagram mode can be cautious
       May be inappropriate for NSLPs that want to
        use it to shunt large volumes of data around

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:5/9/2013
language:Unknown
pages:27