UNVERIFIED MINUTES BY MIKKO SÄRELÄ AND JOHN SCUDDER INTAREA Internet Area Open Meeting TUESDAY, December 4, 2007 1520-1720 Afternoon Session II Salon D/E Area Directors: Jari Arkko and Mark Townsley 1520 Notes takers, blue sheets, agenda bash (5 min) 1525 Area status update (ADs, 10 min) - BOF situation - Major WG news - "area drafts" and their status 1535 RAO IANA Considerations, Jukka Manner (5 min) http://tools.ietf.org/html/draft-manner-router-alert-iana 1540 RRG Update, Tony Li, (15 min) 1600 240/4, Eliot Lear (30 min) http://tools.ietf.org/html/draft-fuller-240space 1625 DHCP-based Authentication, Jari Arkko, Ralph Droms, Ric Pruss, Mark Townsley (50 min) http://tools.ietf.org/html/draft-pruss-dhcp-auth-dsl Notes: 240/4: The Future Begins Tomorrow -- John Eliot Lear See slides - Options: make 240/4 unicast public, unicast private, split it up some way, or do nothing - Some urgency if we want this to be relevant at all (due to looming v4 space exhaustion) - It takes time to make the required changes in the network - draft-fuller-240space-00 says: make code changes now in order to enable any of the above options - Some running code already Mic: - Vince Fuller: 20 min to change Linux. - Erik Nordmark: (BSD implementation issue I didn't follow) - Alain Durand: This is very amusing as an experiment, but it doesn't mean I can use this in my network. Seems like a fantasy. If we want to deploy this in the real world, we need a better analysis than just a little Linux patch. Frankly we think going to v6 is easier. Plus a /4 gets you a year worth of growth, and will take years to deploy. Basically, this seems counterproductive, waste of resources. - Dave Thaler: Assumption that code change is agnostic of whether address space is public/private is simply false. For example, 6to4 only works if your address is public. Other examples exist. I need to know public/private status before making code changes. Also, I think the best you can do is "consenting adults" case, I don't think this will ever work in the big-I Internet. - Eliot: Regarding Alain's point, we're not suggesting anything regarding v6 migration. I understand your point about resources. But 6.25% of the address space seems like too much to waste. Also connects to discussion of "what happens next" when we run out of v4 addresses. Notion people can just simply move to v6 is oversimplified. If we can make it less painful by providing extra v4 address space, that's good. - Alain: This is not specific to cable, please stop using that example. Second point, the longer we keep wasting time, the harder the v6 transition will be. Plus this is not IETF business. - Iljitsch van Beijnum: Not feasible to change all host and router software everywhere in the universe. Will not ever be usable as general usage address space. Just forget about that. Good to do this but don't kid yourself. - Jari: Regarding "make this decision [to change software] now, then decide status of space later" -- how long do you think it will be until the space is actually useful? - Eliot: Depends on the use as to when it will be useful. If limited/restricted, sooner. If more general, later. Best case 1 to 2 years, probably a couple of years beyond that. - Eric Flieschman: We can agree that if we don't make this change, then it definitely will never work. So, encourage vendors to make the change. But, private vs. public is a key point. I'd certainly hesitate to use it myself. What's the greater risk for me between this and v6? I don't know. - Eliot: Personal opinion: This isn't a replacement for v6. - Eric: Seems irresponsible to call v4 "depleted" if there's still a reserved space. - Wes George (?): I can NAT from this space into conventional IP space. - Dan Turner (?): I have an immediate use for large amounts of v4 private space. Would be immediately useful in my application. - Alaistair Johnson: Similar point to previous two. "Consenting adults" kind of use. - Eliot: would like guidance from ADs. - Jari: sense of room? Hum: Unnecessary or good idea? - Alain: Unnecessary, or unwanted? Good idea or not? - Mark Townsley: Should the IETF recommend this or not? - Alain: or do you mean mandate? - Dave Thaler: consenting adults scenario OK with me. Mandating everyone do it, not. - Jari: even formulating the question is too difficult right now. Area Status -- ADs See slides - Various BOFs announced - Tictoc BOF, second BOF, great deal of interest. Charter received reasonable acceptance, will edit charter, see if we can form WG. - Various IPv4 exhaustion and IPv6 transition related groups and discussions announced (NAT-PT is one item) Issues with the IP Router Alert Option -- Jukka Manner See slides - v4 has one RAO value (0), v6 has 36 of them (0-35) - No procedure for allocating v4 RAO values - NSIS wants new v4/v6 RAO values - v6 RAO has 2 different ways to say e2e RSVP - Proposal: Clean up (create?) IANA v4 RAO registry, fix v6 registry by removing value 3 (which is the redundant e2e RSVP value) Mic: - Bob Hinden: Not much value in harmonizing v4/v6. Mapping between two tables is a trivial problem. - Jukka: main point is that v4 doesn't have aggregation levels at all, NSIS needs v4 values. Don't care if values are the same between v4/v6. - Alex (?): Is this a sort of clean-up effort, documenting existing usage, or what? - Jukka: Yes as to the former, don't know as to the latter. - Alex: I'm using some undocumented values. Can we have an "experimental" value? - Jari: That would be typical. Probably a good idea. RRG Update -- Tony Li See slides - Scalable routing & addressing architectures - See problem statement, design goals document - About 10 active proposals or so - Discussion currently on RRG mailing list, lots of email - This week: Updates to LISP, APT, Six/One; three new proposals - Next steps: floor still open for new proposals, but: measure proposals vs. problem statement, design goals, taxonomy - Drive toward consensus starting March '08, expect to take about a year - Not sure exactly what the process will be yet. - Various proposals are flavors of map-n-encap: this means making tunneling a permanent part of the architecture. This has various issues, including path MTU. We think there are issues with PMTUD. Does the audience agree? Raise your hand if you disagree. (Very few hands.) Mic: - Iljitsch: Regarding PMTUD issue, three choices: Fragmentation for tunneled packets, present a smaller MTU, or support > 1500 MTU e2e. All seem undesirable, need feedback. - Fred Templin: I agree. If egress routers configure a larger MTU though, that would help. Also, encourage RFC 4821 adoption. - Jari: Does that require a path MTU of 2 kB? - Fred: No, just egress. - Ran Atkinson: Obscure problem with Verilog, didn't follow details. Think there are big problems with -encap. No evidence that PMTUD, hosts will ever get it right. DHCP-based Authentication, Jari Arkko (as AD), Ralph Droms, Ric Pruss, Mark Townsley (not as AD) See slides Jari: - Moving away from PPPoE in DSL - Various approaches (802.1X, PANA, DHCP) - Considering DHC recharter - Some proposals minor extensions, others change state machine in major way -- latter should really be done in IETF, not other SDOs - Desired: present proposal, discuss implications, sense of room on whether to do DHCP work on this, if no get guidance on alternatives or if yes guidance on details - Need this before DSL forum meeting next week - But, decisions on list - 180M DSL users, many providers and proprietary additions which cannot be upgraded. Incremental approaches and usage of old considered necessary. Mark: - Migration away from PPP to IP in industry (DSL, etc) Mic interrupt: - Bob Hinden: what's driving this change? Why don't people like PPPoE? - Mark: we could discuss this at great length but the bottom line is, it's happening. Mark: - detailed discussion of DHCP subscriber line "option 82" authentication, see slides (this is starting point, not draft-pruss) - current situation fine for many, but not all cases. insufficient for: migration from existing systems, cpe controlled retail isp selection, very large/operationally chaotic access layer deployments - further details of draft-pruss, see slides Ric: - eye chart, see slides - alternatives: - alternative 1: dhcp-auth as "drop-in" for PPPoE without new DHCP messages - alt 2: dhcp-auth with eap pass-through - dhcp authentication: think messages will fit comfortably into 1500 byte pkt (but see Fred Templeton's draft if you're worried) - what if home GW is a bridge? Discussion of arms race with using option-60 for differentiation. - IPv6: various open issues (link local, different addresses per service, blah blah). To be addressed in future draft. Mic: - Sam Hartman: EAP peer is home GW who's also generating DHCP discover. - Ric: Not guaranteed always. - Sam: What are the other possibilities? - Ric: STB on bridged CPE - Sam: OK, but is the EAP peer always the guy generatng the DHCP discover? - Ric: yes - (More N-way discussion, packets dropped) - Sam: How can something be both a DHCP relay and a DHCP server? Also, don't use the term "NAS" since it has a meaning in the EAP RFC. - Ric: on the server thing, original draft didn't address relay. Many implementations are servers, which turn around and get addresses from a central DHCP server but look like a DHCP server to the client. Tried to clarify this in merged draft. - (?): You mentioned equal access, also mentioned you want to only change residential GW and NAS. I think in PPPoE there's a thingy that steers sessions based on identity. Does this move to DSLAM as last point of shared facility? Intend to support this case? - Mark: PPP model is blah blah blah. Various way to do wholesale with IP sessions. For example, could use tunnel from DSLAM. Could be VLANs. Etc. - (?): Comes down to equal access model. - Ric: Current alternatives for wholesale are L2 from DSLAM, VRF selection, or PPPoE. Jari: cutting off mic for now - Issues to consider, IETF perspective, way forward - Good to move away from PPPoE - Good to be able to move CPE device around - Good to have an IETF spec instead of proprietary solutions - Multi-SDO coordination is "fun" (DSL Forum, IETF, IEEE) - Potential solutions: L2 (IEEE liason), IP layer (PANA), Subscriber auth in DHCP (draft-pruss) - DHCP drafts in very early stages, need lots of work - Solutions can't be eval'd just on e2e behavior -- implications for home site are important, future developments, limitations of DSLAMs - Challenges in DHCP: securing DHCP transaction vs. using DHCP for acces control, problem with stateless v6, server vs. relay, retrans responsibility, CHAP vs. EAP ("CHAP over my dead body" per Sam), more issues -- see list - Requirements for acceptable solution: - must solve technical issues - must not place req's on hosts - must handle v4 and v6 - must be backwards compatible - must describe limitations/applicability - must conform to existng DHCP RFCs. - Way forward Mic: - (?, ISC): Nothing operational will actually let you have 1500 byte packets for DHCP, 576 is reality. Also: if auth is actually useful that's great. - Ric: MTU size, if it's really an issue we'll deal with it. But, I don't know if we'll get there. - Iljitsch: You should read stuff from mailing list. Your proposal seems funny, but that would be OK if we got a lot of reuse of existing specs. But, you want to change the DHCP state machine and break compatibility. I suppose that would be ok if it were backward compatible, but that doesn't seem to be the case here. Summary, any way you look at it this is both horrible and terrible. Are we going to do this again next year for the cable people? Please don't do this. - Ric: Any authentication method on the CPE has all the characteristics you just mentioned. - Iljitsch: eh? - Ric: This isn't specific to DHCP, it's the problem space. If you want to change how user authentication on the home gateway works, you've gotta touch the CPE. - Jari: yes but if there's an existing solution, that's less worse - (More conversation) - Iljitsch: ok, maybe even the upgrades aren't a problem. but you're going to a great deal of work to do what's architecturally the wrong thing. - David Miles: to be used on NAS, DSLAM? One of big problems with 802.1x is inability to be used with wholesale 'cause you can't tunnel it. - Jari: I thought there was an option for how to run 802.1x through relays? - Bernarnd Aboba: TPMR can theoretically do that. - Erik Nordmark: Architecturally odd to tie together address configuration with authentication. I guess this is convenient but short-sighted. This will actually make v6 harder, and we will need v6 soon. - Ric: agreed authentication must precede addressing. Furthermore addressing can depend on authentication. - Ralph Droms: v4 and v6 are required, but need not both be the same. Not necessarily an advantage to doing both the same. - Jari: agreed - Mark: agreed - Ralph: though they don't need to be the same, they need to be done at the same time - All: kumbaya - Ralph: I fundamentally disagree that authentication has to precede address assignment, also that there is any mutual dependency - Ted(?): No reason to assume relay agent will, or won't, forward big packets -- code never been exercised. Cannot assume reassembly will work. - (?): Also, why does the DSL Forum prefer DHCP over PANA? - Mark: wasn't quite a must in the liaison statement, more of a serious interest. Also, at last IETF chairs thought consensus was for DHCP because some choice had to be made. PANA has been presented a few times over the years. - (?) What's the problem with PANA? - Ric: PANA has to change everything in the auth arch. OTOH, we all have EAP, DHCP, AAA, blah blah -- DHCP arch is close to current implementation unlike PANA. - Bernard Aboba: If you consider Jari's list of requirements, can you satisfy them all with just the simple CHAP mode? - Jari: probably if we can silence Sam - Ric: we started with just CHAP and so did Huawei, but we have been beaten up about vulnerabilities - Sam Hartman: seems neat, but please do it securely. assume new environments, authentication protocols, etc in future. Implications: EAP, well-defined endpoints for auth, accept that someday someone will use SA for something e.g. integrity protecting DHCP conf data. - Fred Templin: Can spec that server has to have MRU of ~2k. For relay, check out my draft about DHCP frag & reassembly. Second, I think we can use this in other environments such as MANET. - Jari: why would this be relevant in MANET? Packets would still be totally exposed, there is no media-level access control. - Fred: Maybe you could use 802.1x for access control. More analysis required. - (?): regarding auth before address allocation, in PPPoE that's how it works. NAS tend to be optimized for that. This proposal seems like a good start anyway. - Suraj Patel (?): DHCP is the path of least resistance so that's why you want to overload it. But, the amount of changes required on the home gateway and other elements are so significant it's not necessarily going to be so easy. Also since it's going to be an incremental upgrade, choose something appropriate. DHCP isn't necessarily the right protocol. I completely disagree with Ralph -- access must precede address. - Alper: before we reinvent PANA or even PPP over DHCP, shouldn't we understand the problem space, what are the requirements? We're jumping the gun. Need requirements analysis as the IETF. Follow our own process. - ? Das: I had the same question as Ted. Why isn't PANA a good fit? - Ric: We assume DSLAM provides L2 scurity. With PANA you need a whole new solution for L2 security. There is quite a long list of issues iwth PANA. - ? Das: I'd like to see that list. - David Miles: (unintelligible) Jari: We're out of time. I'd like to get an initial sense of the room. Question: should we pursue this or not? Hum if you think we should not go forward. Hum if we should go forward. ([Both] Note takers think: about the same volume.) OK, try again with show of hands. No (about half hands go up according to note taker. Count about 50 from chair). Yes (also about half per note taker [both again], chair says about 35). Jari: appears to be a slight preference for not doing this, though somewhat inconclusive. Discuss on list.