notes - technical plenary (IETF 73)
19 nov 2008

tech plenary:

1. Welcome

(olaf) only one plenary this time
- the goal is to try and open up more meeting time in agenda
- and also there is some consideration of meeting venues, since sometimes it is necessary to rearrange rooms for the plenary
- we will start with the host presentation, then the IAB technical plenary
- after the snack break, will have management plenary
- after which will have *all* the open mic time (IAOC, IESG, and IAB)
- will end late - close to 8 o'clock


2. Host Presentation  (google)

(chris dibona) i am chris
- i will not take up too much time
- a great strength of the ietf is that you don't spend too much time with people like me
- it actually is about rough consensus and running code
- if you care about me, you can look me up with a search engine
- or come to the talk tomorrow at 1 o'clock

- google is actually proud to be the host / sponsor
- because of the important work that you do



- vint brought up the idea of hosting about a year ago
- it is a fair amount of money - we thought about it for a while
- and decided that it was the right thing to do
- not just standards, but also code

- so why do we care about the internet?

- google crawls the internet, indexes it, and serves it back to you
- that works because of open standards and open source
- without these the internet would not exist, and vice versa
- that is why we care

- i used to run a mail server for a law form
- one of our IP attorneys said "you like the Internet thing"
- you geeks kind of screwed it up..
- if you had patented it right you could have earned a penny for every packet
- do you think that Internet would have grown the way it has if we had done that?

- what we came up with is much better because we can all use it
- based on openness...

- that is it
- "the internet is broken, and it has been for 30 years"
- but that's a good kind of broken






3. IAB Technical Plenary: Evolution of the IP model
(http://tools.ietf.org/id/draft-iab-ip-model-evolution)

(olaf) back to the technical plenary...
- i would like to invite all IAB members on stage
- we will present on a topic that we are all working on
- this is something of a "working session of the iab"
- please hold questions until the end
- questions only on the topic, open mic at the end of the next session


(thaler)
- a couple of years ago, Lixia said "we talk about these assumptions, maybe someone should write down what this service model is"
- that is partly what got this started

- what do we mean by the IP model?
- it is the service exposed to upper layers (see chart)
- in the beginning, IP was published as IEN
- moved to RFCs
- and 791 in 1981

- by 2004, RFC 3819

- RFCs made various assumptions that were not always documented
- not in one place, not necessarily well-known
- maybe not even true (any more)

- the goal of this IAB work is to collect these assumptions in one place
- assess their truthiness
- and provide some guidance

- we presented some of this to subsets / WGs in dublin
- request to provide input to the IAB, so can come up with some guidance
- trying today to focus on the guidance part
- and a little about the assumptions (since not presented to everyone yet)
- not talking about the entire draft today

- 791 defined the basic IP service model
- senders can send without signaling a priori
- receivers receive
- packets of variable size

- strong host and weak host

- if you enable forwarding, that is a weak host
- as a result, you see different IP implementations, some stronge, some weak

- but there are other things that people assume that are not in RFCs (explicitly)
- assumptions fall into 4 general categories
- connectivity
- addressing
- upper layer protocol extensibility
- security

- snopes has a model: claim, status, examples
- everything we are talking about is "partially true"

connectivity

- reachability is symmetric
- there is the simplest call-response
- immediate, today-tomorrow
- call back over a longer period
- lots of reasons why this is not true
- 802.11 ad-hoc and related technologies
- admission control proxies
- UDLR was one attempt in this area
- response request today usually works, but not longer-time frame callback

- reachability is transitive
- lots of things have that assumption
- doing referrals, callbacks
- same things interfere here

- another assumption in this category is that the end-to-end delay of first packet is typical
- e.g. pick among candidate servers
- pick first responder - but not always true
- data triggered look-ups
- protocols that have a notion of path switching
- follow one path initially, then switch to a more efficient path
- if you have another destination that has already switched you may pick the wrong one
- end up with longer paths, higher load, etc
- entice you to look at the draft

- iab found that causes of violations tend to fall into two categories
- layer 2
- or things we've done at layer 3

- usually l2 is not trying to break IP
- it is when running IP over them that the problems arise
- RFC 3819 does a good job with advice

- for those that define IP over foo, should try and compensate when practical for these shortcomings
- e.g. UDLR
- IP over NBMA
- just examples


network layer technologies

- we like reachability
- everything can talk to everyone
- until we start getting things we don't like getting
- unwanted traffic workshop
- only want to be reachable by the good guys
- notion of restricting to authorized senders is already a core part of the IP model
- e.g. IPsec
- wasn't there in 791, but it is part of the current model

- when reachability is affected for reasons *other than preventing unauthorized traffic*, we should try and solve or avoid

- this notion of trying to hide it
- the IP model was something that was exposed
- one way that people try to solve or avoid is say that for a link type, it only goes between two routers
- don't let upper layers see it
- not only work on avoiding or solving, but also diagnostics
- we have apps making assumptions
- when something goes wrong, not easy to explain why

- postel had a principle
- this is different but wording is inspired by postel's principle
- when defining a protocol... (see slides)

- if the link layer can already have this oddness,..

- half of the IETF is network and below, and the other half is transport and above
- upper layer should try to avoid assumptions where practical

- issue of NBNA links
- lots of 6to4 traffic
- but doesn't support multicast
- often don't have wide-area multicast in the Internet either

- adding multicast to 6to4 isn't necessary until you actually have widespread multicast

- lower layers should avoid making them less true
- and consider the effects on upper layers
- acknowledge them explicitly


Addressing

- addresses are stable over long periods of time
- e.g. behavior of common APIs
- sockets
- call a name resolution API, then connect
- when you resolve in the DNS, you get a TTL
- but the TTL is not present in the API
- apps cache address and have no clue how long they will be valid even though the host has the information
- mobile hosts
- some effort to restore this
- proxy IP, mobile IP, HIP

- while a host has only one address and one interface
- call name resolution and use the first one
- saw this in a lot of applications when adding v6
- often you have DHCP options
- option is obtained over a particular interface, not how to convert to a host-wide property
- no guidance on merging information

- we have dual-stack
- VPNs
- to some extent, mobile IP, HIP, ...
- gives something that the apps could use

- assumption that the address an app uses is the same one that routing uses
- examples...
- make assumptions about the relationship between proximity in the address space and proximity in the topology
- nodes on same subnet are always close

- some apps / protocols try and select a server based on the client's IP address and how it relates to the candidate addresses
- most but not all loc-id schemes not true, some in core of the network are true

- point is to get a couple of examples - help to motivate the guidance / discussion

- what does the IAB think?
- RFC 1958 - apps should try and use names
- bunch of client apps that deal with sockets
- this is largely an API issue
- there are also protocols that only carry addresses (and not names)
- it would be good to change this

- anything that is already dependent on a naming system should try and avoid addresses and only use names
- stuart talked at last the plenary about connect by name
- this also happens to ease the v6 transition
- apps don't need to be changed

Upper Layer Extensibility

- new transport protocols can work across the internet
- deering hourglass
- there are new things being designed
- TCP, raw sockets, things that rely on this assumption
- NATs and firewalls only support TCP / UDP
- or only HTTP

- bad hourglass
- rosenberg talked about new waist of the internet is moving up
- actually worse than that



- things that open a bunch of connections
- e.g. for more throughput
- one for data, one for control
- there are some things that will interfere
- firewalls might block specific ports
- middleboxes that have per-connection state that may run out
- just because you can get one connection, maybe you can't get 4
- all of these are partially true

- RFC 791 doesn't describe the requirements
- but these have been discussed
- in the appendix of clark's doc
- clark - here is what we were trying to do
- e.g. service generality
- widest possible range of applications through a variety of types of service at the transport level
- some due to address shortages

- same guidance as before
- aside from getting rid of unwanted traffic, IETF should try to avoid or solve

Security

- assumptions are in the draft
- there is a pretty good RFC 3552
- already has great guidance

- other things that are security related
- anything that is basing behavior on these assumptions, those have security effects
- relying on an untrue assumption may be introducing certain security property

- not just the obvious things that will break, could have upper layer consequences
- upper layers should carefully consider the basing of security on assumptions about underlying layers
- lars presentation about transport...

- many of the violations were done in the name of security
- for example, the symmetry
- some may be violated, but could be a good thing

- conclusions - any changes to assumptions can break some apps
- if talking about the public internet
- one or two or more

- ossification of the internet
- so many things built on these assumptions that it is hard to change

- IP is not static, this is evolution...
- it has been changing since the beginning
- just that changes must be done with extreme care

- don't change unless the guy above it asks for it
- trade-off between opt-in vs default

- if you work on network or below, consider the impact to upper layers
- write it in documents
- if at transport or above, avoid assumptions when possible
- this doc is a list to aid in writing applicability statements
- know which environments an approach is good for

questions:

(phillip hallam-baker) i think the advice is wrong
- discovered this with html
- web browsers would work better if they rejected bad data
- heuristics based programmer creates traps
- result is more incompatibility, than less
- need to be careful with the more liberal
- object-oriented concept of contracts
- if you make only these assumptions about lower layer, then we are going to keep your app running and compatible
- if your app makes these sets of assumptions, these are the ones to ...

- move less from assumptions and more to a contract between the apps and transport
- forget about IPv4 or IPv6
- as app developer, want to design something that could go on for years
- v8, v10 or

(stuart) agree with what you said
- the principle of when to be liberal needs to be applied selectively
- if bringing a new protocol to market, make it strict

(thaler) in the example you gave, browser doing something
- not something the IETF would have been specifying

(hallam-baker) the way we wrote html
- caveat with what to apply
- being liberal can create more rope

(thaler) discussed
- if you want to be liberal in what you accept - there is complexity
- sometimes worth it or not
- still working at this - input appreciated

(oran) one of the struggles is how much of the subtlety gets loss in a simple statement
- how much should apps stop assuming that IP does reasonable things, and work around breakage, unreasonable things, still struggling with how to express those trade-offs
- if every app needs to write complex code to get around a weird set of NATs
- can't assume any transitivity,
- would move the waist the whole way up to the app layer
- working on this guidance
- NATs, firewalls break everything
- on the other hand, idea that apps need to build this extra stuff
- could use input from the community

(barry) on html
- character sets are not specified properly
- that is a broken implementation - did not follow the std
- that is not what john postel was talking about with liberal vs strict
- assumptions that were valid, observe that no longer the case, and change based on that
- on contracts, i think that is what we try and do, with clear specs
- but people make observations and assume that the observations are valid

(lixia) we are IETF - think connectivity is good
- we build apps based on idea of global connectivity
- succeeded
- internet has grown large in size, so things have changed, more "noises" now.
- we should still build apps assuming connectivity, but also apply robust checking principles
- build upon the assumption, at the same time also detect failures
- the larger the system, the more the unexpected failures.
- We simply need to be able to detect and handle failures, not walk away from the basic assumption.
- building everything on top of http is not the right direction

(andy) there is still value in the quote
- keep in mind where people follow protocol spec
- field written as 0, throw away if not set to zero

(jeff hutzelman)
- if html did not require parsers to be liberal, it would have been impossible to extend fames or scripting
- that worked equally well for browsers that support those features and those that didn't

(barry) there you are specifying what you should ignore (don't understand)

(jeff) that is what john was referring to
- be liberal on what you receive

(hallam-baker) we didn't require things that were well formed syntax
- e.g. not close tags
- that is different than ignoring fields that you don't understand

(stuart) well defined extensibility mechanisms about what to ignore are fine
- guessing on where to close a tag is bad

(margaret) thank you for writing this doc
- i think this is good work
- a few comments that are all about what we are going to use this doc for
- extremely valuable if the purpose is to understand what we have now and inform editors, authors, on what to do
- i think that is what you are saying, but...
- capturing that evolution is good and important for the internet
- we don't want to stop evolution
- things get turned from informative to proscriptive (sometimes not on purpose)
- also, a lot of things that changed this model happened outside this IETF
- e.g. doom
- NAT, l2, grew outside the IETF
- stuff that was very popular and widely deployed, and made the internet better
- but hopefully we can get them to read the doc
- we don't want to slow our ability to evolve the internet
- e.g. review, adding a considerations section in every doc
- we will not slow down the outside stuff, and so we would just be putting ourselves at a disadvantage
- i think phil's contract idea is bad, because we want to support evolvability

(gregory) we have been talking a bit about how much to be prescriptive
- some people want the IAB to be prescriptive
- tell me what to do, how it effects the design work
- said be careful about prescriptive
- is the prescriptive needed in these assumptions?

(margaret) only speaking for myself
- would like the IAB to give sound advice and good tools
- where an IAB member sees a working group making assumptions, this doc is a tool, advice
- i think then the work itself has more weight than if you try and make it a rule
- postel's advice...
- didn't try to make it a "rule" - more influential to give advice and document
- but also this stuff is not obvious
- it brings together a lot of stuff

(gregory) the take-away is provide advice, not a rule, to use as a measuring stick
- breaking advice or not
- and consequences that are likely

(oran) reflecting on the various examples used here..
- the focus of the document has a lot to do with the vertical
- what are added to lower layers that may affect these - make the app harder
- it is not in a p2p sense, i.e. what one peer can assume about another peer's intent
- that is also an interesting area, on  the p2p level, but
- our observation was that the evolution of layers independently has happened under the covers without really getting embedded in the app designer or service specifiers brain
- this doc tries to focus on the cross-layer

(margaret) agree
- my ref to postel was just..

(oran) i am reacting to the http example, which is more peer to peer

(margaret) good advice takes on more of a life than prescriptive

(barry) on contract, agree that we don't want to arbitrarily restrict what wgs can do
- phil was talking about contracts in the object-oriented programming sense
- black box - know what you're getting in and out
- clear specification

(thaler) one use of this
- when doing an applicability statement that is something like a contract
- when doing requirements, chance to observe about what services you are assuming
- that is the closest thing to a contract that many wgs get to

(aaron) i am sensitive to the point that postel can be interpreted to mean handle all possible permutations of topology, etc..
- one element of this is really to fail gracefully, and report failure
- what things are continuous over time..
- put text in the specs that if something doesn't happen like we thought, send up a message
- make it easier to diagnose why it has failed
- this is one of the problems arising from middle boxes, behavior changes, hard to tell why things go wrong

(christian vogt) one more assumption
- if as mobile host moves, there could be more than one address that changes
- the protocols we have today are not dealing with that very well
- NAT traversal solutions that work during connection, but not in the middle
- and verification ...

(thaler) impact to the upper layer, in most cases, is not directly involved in causing the mobility
- it comes from underneath
- its address changes
- i think this is a variation of the assumption that addresses are stable
- will look at that and see whether to add

(iljitsch) i think it was a good point about names rather than addresses
- wished this had happened when working on multi6
- v6 people also
- we can agree this is a good thing to do, need to address why people not doing this today
- complexity of naming / discovery layers
- why enterprises using addresses
- dns probably has some reliability, performance issues that needs looking
- i think DNS just can't do what needs to be done right now
- names available to hosts that don't run a server
- dynamic dns, etc...

(thaler) yes - general statement
- does host have a name?
- do we know why - the apis deployed today do not have connect by name
- v6 still using the same APIs that were done 20 years ago
- they don't reflect the RFC 1928 suggestion
- time for us to do that in the OS
- do clients all have names - how to provide names to to server, etc

(lixia) i like iljitsch comments
- how can you evolve the current system toward more use of names
- this requires more work to get there
- need to fully understand the tradeoff of using names
- e.g. resolution time
- those issues need to be stated, addressed
- to achieve the goal of promoting more use of the names

(oran) at the risk of rathole
- agree there are other problems here
- how many have tried to do key management for DNS update
- how many like what we have
- work to do to allow dynamic dns to be relied on
- in all fairness, it looks like the

(aranen?)
- address stability and multi-homing
- we should be careful not to oversell
- applying to end-to-end
- if you are multi-homed, not all your mobility handled by mobile IP
- dangerous to assume you are getting anything from

(thaler) agree
- just saying there are things we are doing
- one example
- doesn't get you to the top
- but app might work better 5% of time

(?) 5% is pretty low
- for an app to take advantage you need to tie the app to behavior of mobile IP modules
- this is harder

(thaler) in the multiple addresses RFC
- whichever is the default, the OS can do something
- in this case, if default, apps will use home address
- some control at the lower layer
- app inherits

(olaf) we have some time left for discussion, but i still want to close the mic

(dave crocker) thanks for this work
- especially this well done
- nice to see the IAB do work that is reflective, integrated, and practical
- the fact that this paper teaches us lessons learned reminds us that we needed to learn lessons
- suggests there is an ongoing dialogue
- paper does this well, rather than giving answers
- confusion about that phrase suggests more lessons
- the web craziness of excessive liberality has been seen in pretty much all apps to have the receive side to complain to the receive operator

- on the slide about locators
- and one deeper lesson, name / locator discussions..
- what are assumptions about the use of the name
- paper could use more here
- true that DNS can't serve some types of uses, but some it can

- when mentioning about tunnels, i wasn't understanding how this related to loc-isd and above text

(thaler) when doing a tunnel, we mean there are two IP headers in the packet
- there are two addresses, one in each header
- the outer header is used for routing during the tunnel
- the one inside is used by the app
- they are different

(matt mathis) awesome piece of work
- advice...
- wherever you do "be liberal" there should be a pedantic mode that should stay in the stack
- turn on pedantic mode, see the errors
- e.g. of compilers
- clearly not the main point - footnote
- but would help a lot

(thaler) agree
- this is inline with "diagnostics is key"

(oran) also falls in here
- one of the first things broken in security is diagnosability
- assumption that adding diagnosability introduces security problems
- e.g. firewalls that drop ICMP
- these are hard to justify...

(james woodyatt) thanks for this doc
- i also like this statement, essentially (last slide) pragmatism
- i think this could be helped by adding "set clear limits"
- looking for particular recommendation
- RFC keywords are pretty cool
- be liberal is "MAY" keyword, conservative is "MUST NOT"
- uses of these keywords, how many are MUST, MAY, et
- if not enough MAY, MUST NOT, ..
- does it feel like there are appropriate limits

(barry) i am at odds with you on MAY
- that is not setting limits, but leaves it up to implementation, i.e. we don't adequately specify the contract
- i would most often like greater specificity

(james) kind of at odds with how we have defined MAY
- should be redefined as "this is what those people are allowed to do and I have to respond"

(barry) i think it does apply, MAY on receive, MUST on send

(thaler) sounds like we agree on MUST NOT
- maybe actually you are arguing for a different term
- MAY is what "you" are allowed to do, not what someone else can do to you
- setting limits and expectations on others is different
- that is not the capital "MAY" in 2119

(gonzalo) the problem is how qualified the term is
- SHOULD because of ...
- unqualified SHOULDs are difficult to handle

(?) thanks for this doc
- worried that this will be out soon
- future IAB will see these are not right
- how to handle evolvability?
- IAB look at this every so often?

(gregory) the model should change over time or you are not doing your job

(thaler) the IAB does a bunch of things and we spend effort on what is most important at the time
- in 10 years, this may be important
- over time this will be less true

(lixia) i think you touched a potentially profound point
- we should recognize that a successful architecture also evolves as success brings growth
- technology also moves forward
- as a result the various assumptions should be periodically reviewed

(kurtis) go back to first list
- those history is equivalent to what we are trying to do here
- last was 2004..?
- no one addressed the topic for a few years
- may have been stable over time, but now seeing new assumptions

(lixia) not everything changes, some immutable
- the global IP connectivity should be kept (requires effort to maintain)

(?) this is the IP model, if you break this, need to update these other things
- do a revision
- IAB reviews all docs

(alain) how do we react as a community when fundamental assumptions change
- e.g. IP address uniquely identifies an endpoint
- with NAT, uniquely identifies a user
- what is the effect on the other side
- on the higher level...

- someone trying to log in, too many failures from one address, block that address
- but if that address actually maps to 1000 users, it won't work

(thaler) the assumption you refer to is in the slide
- you should be using names rather than addresses
- be liberal in what you accept...
- we are interested in more input

(oran) alain puts up a new point
- we talk about the downward implication
- this is a third party making assumption about what is going on
- e.g. one principal responsible for an address
- not sure if we considered this

(stuart) this is a good observation
- i login from ssh and get the message "last logged in from address X"
- that address could be anyone on my street

(thaler) there is other assumption partially covers this
- it is talked about here
- could be more explicit

(alain) not sure names really help here
- assumption that is no longer true

(gregory) completely agree
- we just having conversation about how to do this
- haven't sunk teeth in deeply enough yet

(wheden?)
- 1122
- what is implemented

(thaler) IPv6 tended to pick strong host
- early windows weak host
- v6 RFC came out - recommended strong host
- some security issues based on weak host
- IETF is closer to saying "use strong host"
- windows also switched to strong host

(wheden?) weak host has been based on IP address selection...
- mobile terminal...
- selects based on host interface..
- IP model assuming...
- PC is just on internet interface, mobile terminal had multiple
- mobile terminal can really use multiple interface simultaneously

(john klensin) thanks for taking this on
- and initiating this discussion
- i was hoping braden would have said this
- the discussion of the "robustness principle" is fascinating in how short a time it takes for institutional memory to be replaced by mythology
- what i think that means
- we didn't try to specify every detail
- because we didn't think we could get is all right
- what that principle was about - wrote specs in a relaxed approach - this is a metarule
- not "how sloppy one can get"

(danny) i agree on one hand
- but i think you could adapt this to specs, people to mic comments, etc
- everything...

(thaler) this guidance is slightly different than the original principle

(oran) served as inspiration

(??) isn't v6 the last chance we have to restore a green and simple service
- and the way we want to push the world

(oran) i think most of the forces are still there in v6
- address shortage is one reason, but not everything
- people thought they were getting something out of NATs, not just for address shortage
- separate discussion about what things at layer 3 should do - breakage they may cause

(??) what are these other reasons?

(gregory) there are certain trends that we have tried to pull out that are related to our success
- if you can't connect, don't worry about unwanted traffic
- once you have success in connectivity, you gain new requirements
- an analogy
- most of us don't have bodyguards, but you become famous and you need them
- that is one example why v6 can't be simple in the spirit that you asked

(??) is the IETF wanting to push IPv6 to restore some of the end-to-end properties?

(gregory) there are ways that we should try to make efficiencies
- there is a certain level of simplicity that i think we all yearn for that we will never get back to because of our success

(thaler) as oran mentioned, v6 does solve the address shortage problem
- there are other oddities unrelated to v6
- v6 will not make firewalls go away
- opportunity to do some things, but not everything

(russ) please be back in your seats when we resume - 10th anniversary of postel
- break, presentations, open mic