BEHAVE minutes, IETF82, Taipei, November 2011 Chairs: Dave Thaler, dthaler@microsoft.com, Dan Wing, dwing@cisco.com minutes by Paul Selkirk audio: http://www.ietf.org/audio/ietf82/ietf82-3fbanquet-20111117-1506-am.mp3, starts at 14:42. document status: 1 published, 3 in iesg pipeline, 2 close to finished Logging NAT events (Senthil Sivakumar) -------------------------------------- presenting this first because it may have an impact on CGN Requirements should the draft specify a protocol? lars: woefully underspecified, cf. mibs shin: please consider specific transport protocol dave harrington: iesg will push back if you don't specify a mandatory protocol; goal is to get interopability; either specify (with justification) or don't specify (with even stronger justification); see rfc3444 for difference between information model and data model; if you're specifying a data model, be very specific about what each variable means Carrier Grade NAT Requirements (Shin Miyakawa) ---------------------------------------------- issue 1: IPR claim asserted dave harrington: the ietf has specific rules relating to handling ipr dan: there are no ipr claims made in this link, nothing there brian: there is a long string of digits there, so someone could look it concensus call: all in favor of "do nothing and move forward", none opposed. issue 2: informational sections - make logging and bulk port allocation normative? Alain: important for law enforcement to do its job. Irrelevant how, as long as they can do it. lars: lots of timers and rate limits, but no language about preventing resource exhaustion. Once wording about resource exhaustion is added/tweaked, the wording about timers and rate limits can probably be removed or de-emphasized. conclusion: keep generic statements on logging, no details. NAT64 Discovery Heuristic (Teemu Savolainen) -------------------------------------------- Andrew Sullivan: option 2 is the right one (option 2 of slide 8 of http://tools.ietf.org/agenda/82/slides/behave-8.pdf) Teemu: comments on name 'ipv4only.arpa'? Andrew: this is the only place you can do this. (This is a terrible idea, but if you do it, this is the way to do it.) NAT Behavioral Requirements Updates (Reinaldo Penno) ---------------------------------------------------- Lars: be careful between clarifying existing rfcs and changing them; e.g. 4 minutes is a change; okay to say you can shed load if you're overloaded Lars: NAT looks like a TCP sender to the network, and there are existing requirements for that Reinaldo: maybe define overloading Dan: how many people read this draft? (5) Dan: in 2006, we set out to just document what happens; NAT64 and DNS64 are new things, so we specified things Lars: structure doc into clarifications, proposed changes, and security related changes Reinaldo: okay Dave Thaler: increase scope of doc to include NAT64? Reinaldo: wanted to capture operational experience Alain: don't be religious; there is value in this document Roberta: there is value, captures operational issues we've found Lars: 1) address holes in current specs; 2) change requirements/recommendations we've already written; 3) describe security issues Deterministic Address Mapping to Reduce Logging (Chris Donley) -------------------------------------------------------------- 50,000 customers per cgn(!), petabytes of logging data Lars: that data is highly compressible Lars: good to see more data about usage Lars: is this sufficient to satisfy law enforcement? Alain: see rfc6302 Nejc: don't see why we need this as a separate draft Andrew: this is fascinating work, but it shouldn't be an internet draft, and we shouldn't do this Roberta: this is a current problem for us, even as we move to v6 Lee Howard: what she said. But if i'm forced to CGN, then I need a mechanism to respond to legal requests Reinaldo: I support this draft Chris: keep this as a separate draft and keep going, or what? Dave: not enough information Dave: there was IPR posted on this NAT444 and DS-Lite Impacts (Chris Donley) ----------------------------------------- significant improvements in nat444 since last year; ds-lite comparable Lars: did you do the same tests without cgn? Chris: yes, and none of these issues existed without cgn Richard Barnes: did you test across different cgn domains? Chris: yes Marc Blanchet: what do we do with this data? Chris: just trying to show the state of the industry today Dan: did the ietf do something wrong, or is this just how it is? NAT44/LSN Deployment Options and Experiences (Victor Kuarsingh) --------------------------------------------------------------- Victor: does this document belong in this working group? Dave: probably ops area Alain: this doc is valuable, and i'd like to see it done in behave, not fair to keep bouncing it from one wg to another Andrew: this is interesting, but this is not appropriate to the ietf Victor: operators are going to have to make decisions based on what's available Alain: it's wrong to abandon work on ipv4; operators need working solutions while moving to ipv6 Lee: ietf's job is to make v6 better, not work on v4-only; but we need to document approaches that work Radius Extensions for CGN Configurations (Dean Cheng) ----------------------------------------------------- Dave: is this specific to NAT44, or also applicable to NAT64? Dean: applicable to both Dave/Dan: is there interest in pursuing this work? Conclusion: Take it to the list NAT MIB bis (Tina Tsou) ----------------------- Lars: how does this relate to the first presentation on logging? if this data is in the mib, logging becomes easier Reinaldo: we already had to do this with a vendor-specific mib; standardizing is great Christian Jaquenet: ds-lite mib is in softwire charter, would like to see coordination; no sure a global mib will address specific concerns of specific technologies or vendors Dave Harrington: decision made long ago that technology areas should write their own mibs; behave is the right place to make a mib that relates to work that behave is doing; seeing a lot of items that don't relate to things that behave is working on, will need to be convinced. Would be supportive of a WG milestone for this work. IPv4 Address Sharing: problem, solutions, and test results (Jaqueline Queiroz) ------------------------------------------------------------------------------ testing competing host-id proposals using tcp options Lars: TCP option space is too scarce to be wasted this way Marc: useful to get information about implementations in addition to raw numbers; also gather information about deep packet inspection in test paths Stuart: is there anything to prevent me spoofing host-id? Dan: provider wouldn't trust host-id blindly, would weight that in addition to observed behavior, such as legitimate user logins from that IP address. Lars: there is no space in tcp option space for a transition technology side-effect Lars: see IRTF Applied Networking Prize paper from Michio Honda for what middleboxes do with TCP options SD-NAT (Alain Durand) --------------------- ?: doesn't this break port randomization Alain: port randomization happens within the port block at the host/cpe Eric Vyncke: this isn't really stateless Alain: this is per-customer state, not per-flow state Marc: this requires modification to cpe; what happens in mixed deployment? Alain: this is only a configuration change on the cpe, not code change; provider can keep track of which customers are sd-nat compatible Woj: how do you prevent customers from overflowing port pool? Dave: sorry, out of time, we have to move this discussion to the list