Outline of Los Angeles get-together

Reported by: Eric Travis <travis@clark.net>

Note: There was a lot of discussion that isn't reflected here; If the
folks who vocal on the 31st would reiterate their views here, that would
be most helpful. Sorry about any unintentional filtering of the
discussions.
==============================================

Some of the things that we wish to document:
 o Classification/Definitions
 o Common Practice
 o Dangers
 o Limitations of "spoofing"

Full disclosure is important - people need to be aware of what they
are getting into, and the potential troubles they might introduce into
the Internet itself.

Observation: Good spoofing isolates "anti-social" behavior

Document should specify leaf mechanisms vs inside the cloud

Discussion Item:  Policy vs. Mechanism
 o there are probably a few core mechanisms with lots of different
policies

Discussion Item: Transparency is the key
 o  intermediate system action taken on behalf of the 
    end-systems designed to improve (or decrease) end-system 
    performance

 o  For spoofing to work, the spoofer must be trusted - this means 
    that *everyone* would need to be trusted;  

 o Transparency has 3 grades (like an airplane propeller, it can munch
   unaware users)

   1. opaque: change end-systems (time-line problems)
   2. translucent: end systems (1 side) turns a knob
   3. transparent: end systems do nothing (ultimate goal)

Discussion: Time Frames Involved
   - IPSEC - slow-rollout
   - end-to-end improvements
   - want t(ipsec) > t(end-to-end)

Discussion: Why do people "spoof":
                     rate
                        |
                        |
                        |
                        |
                        |
                        +----------- error
                       /
                      /
                     /
                    /
                 delay

        - long-delay, err
        - long-delay, sat
        - LFN, +err
        - LFN, set
        - RF, errored

There was some discussion of the interaction of spoofing/proxies 
and security mechanisms:

IPSEC AH prevents
        o generating false ACKs (need to verify)
        o protects header modification for most of TCP header

IPSEC AH allows you to look at contents of TCP header

Open ended items:

  - Need to formalize goals and objectives

  - Need to figure where (is anywhere) this effort fits into the
    grander scheme of things (relationship to different areas:
    transport, security, application, etc.)

  - People should write related drafts