[10:05:19] --- ggm has joined
[10:35:40] --- herve.prigent@jabber.org has joined
[10:35:53] --- herve.prigent@jabber.org has left
[11:29:17] --- arifumi has joined
[11:30:48] --- arifumi has left
[11:57:17] --- arifumi has joined
[12:01:57] --- keyajima has joined
[12:02:07] --- keyajima has left
[12:32:04] --- arifumi has left
[13:11:58] --- arifumi has joined
[13:25:18] --- ggm has left
[13:51:26] --- mjo has joined
[13:58:53] --- rhe has joined
[14:01:29] --- sam-xzq has joined
[14:01:54] --- dthaler has joined
[14:02:02] <dthaler> where is the meeting agenda?
[14:02:38] --- keyajima has joined
[14:02:50] --- narten has joined
[14:02:51] <dthaler> there it is... addrsel, CPE issues, Teredo server selection, Teredo security, DHCP issues
[14:03:40] --- andrewsullivan has joined
[14:03:42] <dthaler> chairs don't know whether teredo draft authors are here
[14:04:58] <dthaler> recent postings not on agenda... baker-v6ops-b2b-private-routing, van-beijnum-v6ops-connect-method, and draft-curran-v6transitionplan
[14:06:06] --- BillC has joined
[14:07:28] --- FDupont has joined
[14:07:46] --- bruce has joined
[14:07:47] --- dudi has joined
[14:08:02] <dthaler> draft-ietf-v6ops-addr-select-ps-01.txt
[14:08:50] <dthaler> (tim chown asked just before this where the RH discussion is, fred answered just on ipv6 wg list [ipv6 is not meeting])
[14:09:51] <dthaler> currently showing technical comments received on addrsel problem statement draft
[14:12:23] --- jpc has joined
[14:14:47] <dthaler> last updates were posted 2 weeks ago. Fred asks, does this address previous comments?
[14:15:07] <dthaler> fred will let the 2 docs go
[14:15:47] <dthaler> next up: draft-arifumi-v6ops-addr-select-sol-00.txt
[14:16:12] --- terry has joined
[14:16:19] <dthaler> posted to list, but no comments received from list yet
[14:17:10] <dthaler> approaches range from Proactive (configure policy table) to Reactive (e.g. trial and error)
[14:17:58] --- ggm has joined
[14:19:35] <dthaler> proactive approach (configure policy table) in draft-fujisaki-dhc-addr-select-opt-03.txt
[14:19:42] --- miah.ness@gmail.com has joined
[14:20:14] <dthaler> issue: if host is multihomed to two networks, host has to resolve policy collision somehow
[14:20:30] --- David Hankins has joined
[14:21:00] --- sureshk has joined
[14:21:40] <dthaler> another proactive approach: ask some router or server for the answer on demand
[14:22:15] <dthaler> issue: same as above, plus requires more changes/new protocol work
[14:22:55] --- levigner has joined
[14:23:14] <dthaler> reactive approach: update policy table based on ICMP errors
[14:23:40] --- jishac has joined
[14:23:56] <dthaler> another reactive approach: shim6
[14:25:02] <dthaler> picture of domain of applicability on 2 axes: unmanaged vs managed, and static vs dynamic
[14:27:00] <dthaler> Itojun Hagino: there's another solution draft as well that should be considered
[14:27:06] --- pawal has joined
[14:28:23] <dthaler> IH: why are some sources prohibited in the diagrams?
[14:28:53] <dthaler> reason is policy
[14:29:13] <dthaler> Brian Carpenter: even if you use the proactive mechanism, you still need a reactive one for failure recovery
[14:29:24] <dthaler> BC: still need the logic to try the list until one works
[14:30:30] <dthaler> Dave Thaler: right, policy table just tells you what order to try them in
[14:31:07] <dthaler> Alain Durand: deploying this sounds complex
[14:31:47] --- Bob has joined
[14:32:25] --- hotta has joined
[14:33:05] <dthaler> BC: we still need a way for a site to tell the hosts what the RFC3484 policy table is
[14:33:37] --- fred@ecotroph.net has joined
[14:34:26] --- Outdoor83 has joined
[14:34:27] <dthaler> (side discussion between fred and presenter, can't hear)
[14:36:23] <dthaler> AD: almost tempted to say we should do nothing
[14:37:55] <dthaler> BC: IPv6 has multiple addresses so need some solution
[14:38:03] --- ggm has left
[14:38:10] --- josoinin has joined
[14:38:17] <dthaler> AD: multiple addresses are unnecessary complexity in some environments
[14:39:27] <josoinin> Fred: I posted an internet draft on b2b communication based on ULA.
[14:40:06] <josoinin> Fred: If not to use ULA we would have to use dual faced NAT. We don't like NATs, do we.
[14:40:10] --- trond has joined
[14:40:15] <josoinin> Alain: I don't like ULAs.
[14:40:48] <josoinin> Alain: having multiple addresses has issues as it is difficult to chose the right address.
[14:41:01] <josoinin> Fred: the problem is to have multiple addresses then - not ULA.
[14:42:04] <josoinin> Tony Hain: There cannot be a single solution for all the complex problems we have.
[14:42:26] <dthaler> (more discussion of ULAs, really off-topic for addrselection)
[14:44:21] <dthaler> Phil ____?: business-to-business stuff should be using web services not a L3 solution
[14:44:37] <rhe> ____ is Hallam-Baker.
[14:44:44] --- avri has joined
[14:44:52] --- miah.ness@gmail.com has left
[14:45:14] <bruce> 'web services' isn't a solution for everyone.
[14:45:47] <dthaler> back on topic... Fred asks whether this document is interesting to the WG
[14:46:05] <Bob> it generated a lot of discussion......
[14:46:07] <josoinin> Itojun: on B2b communication: You can solve the problem without ULA if you have a tunnel between the two sites.
[14:46:08] <josoinin> Fred: Let's take this problem off-line.
[14:46:08] <josoinin> Fred Baker: We have the general problem of multiple prefixes...
[14:46:08] --- josoinin has left
[14:46:18] <dthaler> some hands
[14:46:45] <dthaler> those who things it's wrong... some, but fewer hands
[14:46:52] --- josoinin has joined
[14:47:02] <dthaler> (s/things/think)
[14:47:15] --- arifumi has left
[14:47:45] <dthaler> fred declares lack of consensus currently
[14:47:53] <josoinin> Fred: Let's continue as an individual draft for now - no consensus.
[14:48:26] <josoinin> test.
[14:48:48] --- arifumi has joined
[14:48:59] <dthaler> next up CPE issues draft-ietf-v6ops-cpe-simple-security-00
[14:48:59] --- frodek has joined
[14:49:10] --- fp has joined
[14:49:16] <josoinin> James Woodyatt: Simple Security in IPv6 Gateway CPE presentation
[14:49:38] <dthaler> "Simple Security in IPv6 Gateway CPE" (James Woodyatt)
[14:49:56] <bruce> draft-ietf-v6ops-cpe-simple-security-00.txt
[14:51:37] <dthaler> context is home/small-office routers typically with v4nat
[14:52:27] <dthaler> gets v6 prefix via native or tunnel, and does v6 native on LAN side
[14:53:18] <dthaler> simple security = outbound allowed, inbound blocked by stateful filtering
[14:56:20] <dthaler> various protocols do hole-punching... UPnP, NAT-PMP, NSIS, etc
[14:56:59] <dthaler> apple went with draft-cheshire-nat-pmp-02 instead of UPnP
[14:57:47] --- terry has left
[14:58:08] <dthaler> IPv6 still needs stateful filters (just not address translation) for simple security
[14:59:34] <dthaler> and hole-punching protocol(s)
[15:00:27] <dthaler> general consensus (IETF, US govt, etc) that stateful filters are required
[15:01:18] <dthaler> "existing IPv4/NAT protocols are proprietary"
[15:01:56] <dthaler> open protocols not widely implemented and possibly not suitable for low-cost embedded devices
[15:02:47] <josoinin> Itojun: I'm guilty for everything on BSD stack...
[15:03:14] <josoinin> Itojun: for FTP you don't have to do really anything.
[15:03:25] --- bnsmith has joined
[15:03:48] <josoinin> James: if the FTP-client starts with passive mode it works.
[15:04:16] <josoinin> Itojun: maybe you should look at openBSD stuff.
[15:04:42] <josoinin> James: I'm much more familiar with OpenBSD.
[15:04:53] <dthaler> AD: how did the WG get a draft-ietf-v6ops prefix?
[15:04:56] <dthaler> Fred: I told him to
[15:05:11] <dthaler> (correction: how did the _draft_ get a ...)
[15:05:53] <josoinin> Alain: The NAP document does not mandate stateful firewalls but say it may be used.
[15:05:53] <dthaler> AD: it's bad to _mandate_ stateful filtering
[15:06:56] <josoinin> AD: Strongly opposed to the comment that everything starting from the home, but everything coming from outside is bad.
[15:07:31] <josoinin> Fred: If I have not contracted it I don't want the operator to operate my home network.
[15:07:53] <josoinin> Bob Hinden: You don't FWs at all, or are you arguing against the default rule set.
[15:07:56] --- terry has joined
[15:08:12] <josoinin> Alain Durand: I understand there is need for security - Though, I don't like FWs.
[15:08:31] --- jpc has left
[15:08:32] --- Bill has joined
[15:08:33] <josoinin> AD: If the operator cannot provide a service it has contracted for there is a problem.
[15:08:57] <josoinin> JW: What should be the default mode is the issue.
[15:09:37] <josoinin> JW: Sympathetic to the too strict FW defaults.
[15:10:29] <josoinin> Hesham Soliman: I understand both sides, but are we the right people to mandate either way.
[15:10:46] <josoinin> HS: It is good to explain the consequences, though.
[15:10:58] --- mg has joined
[15:11:06] <josoinin> JW: Developers deserve the guidance from the IETF.
[15:11:25] <josoinin> HS: Information is good and recommendations. Mandating might be problematic.
[15:11:28] <mg> So, in theory, if an ISP wants to talk to something behind the firewall, there is something there listening, so can't it make a NAT hole? :)
[15:13:17] <David Hankins> well, we could use the same kind of mechanism to open firewall holes, anyway
[15:13:40] <David Hankins> from the inside out
[15:13:43] <dthaler> presenter (JW): many services today relay on UPnP-IGD (or NAT-PMP)
[15:14:12] <josoinin> HS: You're not dismissing UPnP?
[15:14:12] <David Hankins> maybe we should give up on the ipv6 stuff and use SOCKS
[15:14:17] <dthaler> believe UPnP doesn't meet IETF's reuirements for intellectual property
[15:14:19] <mg> Exactly. If the "service provider" has nothing to talk to in my home, I clearly don't use their service, and don't want their traffic.
[15:14:34] <josoinin> JW: We need an open specification.
[15:15:41] <josoinin> JW: The UPnP IPR rules are not compatible with IETF in my opinion.
[15:16:01] <josoinin> Dude from Linksys: Would not ship a product without a stateful firewall.
[15:16:13] <fred@ecotroph.net> The dude is Tom Berbst
[15:16:20] <fred@ecotroph.net> s/Berbst/Herbst
[15:16:40] <josoinin> Tom Berbst: UPnP is what we would implement first.
[15:17:45] <josoinin> Kurtis: If there is going to be a FW by default, what would be the consequences of not having a recommendation from the IETF.
[15:19:22] <josoinin> JW: It would be helpful to give guidance to developers to show what to expect.
[15:20:39] <dthaler> _____?: besides stateful filtering, should say to not respond to DHCP on the WAN port
[15:20:47] <dthaler> and proxy DNS
[15:22:16] <josoinin> Phillip Hallenbeck: More we can do to help security on the home router better it is. Both coming in and going out.
[15:22:42] <dthaler> PH: also egress filtering to block spoofing
[15:23:10] <josoinin> JW: There is some text in the draft, please, look at it and check if it is enough.
[15:23:31] <andrewsullivan> (sp: I think that should be Philip Hallam--Baker)
[15:23:46] <josoinin> PH: Punching holes should be authenticated.
[15:23:47] <andrewsullivan> err, Hallam-Baker, even
[15:24:00] <josoinin> If you say so... ;)
[15:24:08] <josoinin> Fred: Line to be capped.
[15:24:29] <josoinin> Tony Hain: We absolutely need stateful filters and a control protocol.
[15:25:01] <josoinin> TH: As long as there is a signalling protocol, the problems are much smaller.
[15:25:28] <josoinin> JW: That was part of my motivation for ALD.
[15:26:13] --- terry has left: Logged out
[15:26:25] <josoinin> Itojun: Your cell-phone might roam to a home network and you don't get a call anymore. Using UPnP or others just add complexity. We should use crypto mechanisms instead.
[15:26:30] --- terry has joined
[15:27:13] <josoinin> Fred: Two different security with different requirements..
[15:28:12] <josoinin> Fred: Crypto is a good thing, but I don't want a denial of service attack and protect myself of it.
[15:28:14] --- ryanczak has joined
[15:29:20] <josoinin> Iljitsch van Beijnum: It is bad to tell people to run FWs. The hosts should deal with any packets.
[15:30:02] <josoinin> IB: We shouldn't protect the hosts with FWs but fix the hosts. FWs bring many of the problems of the NATs to IPv6.
[15:30:54] <josoinin> Fred: We are going forward with James' draft (WG draft) and continue to discuss the issues - for instance the FW rules.
[15:32:14] <dthaler> next up: Teredo security concerns
[15:32:27] <dthaler> draft-hoagland-v6ops-teredosecconcerns-01
[15:32:51] --- iljitsch has joined
[15:34:17] --- hotta has left
[15:37:38] <dthaler> suresh walking through the recommendations in the draft
[15:40:05] <josoinin> RĂ©mi Denis-Courmont: The port of the client shouldn't be randomized, but the port of the NAT.
[15:40:19] <josoinin> Dave Thaler: That is exactly the idea.
[15:41:14] <dthaler> Dave Thaler: randomizing the client port was the question... what does it help? answer is for port-preserving NATs
[15:41:22] <dthaler> where the port of the NAT = the port of the client
[15:41:29] <dthaler> which is a somewhat common case
[15:42:26] <josoinin> DT: Just a positive comment: I support this document being taken as an WG draft. The implementation I represent support already this.
[15:42:44] <dthaler> (with the exception of the client port randomization)
[15:42:47] <josoinin> Fred: Do we take this as a WG document?
[15:43:29] <josoinin> Remi: We should update the protocol instead. It's not just security.
[15:43:58] --- Bill has left: Computer went to sleep
[15:44:26] --- ryanczak has left
[15:45:20] <josoinin> Jordi Palet: The other teredo document is a different issue.
[15:45:56] <josoinin> JP: It is a document that explains how teredo relays can be found dynamically.
[15:46:23] <josoinin> Fred: Suresh'es document is taken as a WG item.
[15:47:39] --- itojun has joined
[15:48:13] <dthaler> draft-nward-v6ops-teredo-server-selection-00 proposes 3 solutions (2 + the combination of the two) for teredo server discovery, it's independent of the other draft
[15:48:33] --- dudi has left
[15:48:40] <josoinin> Tim Chown: Handling 'Rogue' RAs
[15:48:48] <dthaler> one of the solutions (anycast) is the same as what RFC 3068 did for 6to4 (and I like that solution best)
[15:48:52] --- dudi has joined
[15:49:23] <josoinin> TC: This is the same presentation I did in DHC WG.
[15:49:50] <dthaler> (no draft for this presentation)
[15:50:19] <dthaler> Bogus RAs can be caused by admin misconfiguration, accidents (plug in box into wrong place), or malicious
[15:50:38] <itojun> simple question: why does he not having problem with rogue DHCPv6 server/relay agent...
[15:51:15] <dthaler> (itojun: right, he'll get to that sort of... that was part of my point at the mike in dhc)
[15:51:17] --- mjo has left
[15:51:42] <dthaler> lots of answers today: manual config, SEND, L2 admission control, enhance DHCPv6?
[15:52:07] --- Outdoor83 has left
[15:52:08] <josoinin> Tim's presentation can be found at: http://www3.ietf.org/proceedings/07jul/slides/dhc-5.pdf
[15:53:38] <arifumi> (that's because windows doesn't act as dhcpv6 server even when 6to4 is available, i guess)
[15:53:56] <dthaler> Those using DHCP now invariably don't use authenticated DHCP, so how much better off would DHCP be over RAs anyway?
[15:54:04] --- ruri has joined
[15:54:48] <dthaler> (arifumi: what's "that" in your statement)
[15:55:00] <arifumi> (itojun's question.)
[15:55:26] <arifumi> (i mean the problem of misconfiguration can be avoided at least.)
[15:55:34] <dthaler> Iljitch: you don't gain anything with DHCP
[15:56:41] <josoinin> TC: How many use authenticated DHPC - two hands.
[15:57:31] <josoinin> Craig Daly: Is there something that is missing in SEND or something we missed when doing SEND?
[15:57:39] <dthaler> Greg Daley
[15:59:05] --- fp has left
[15:59:57] <josoinin> Itojun: As a node you have to trust the incoming info - DHCP Auth or SEND are solution. Moving to DHCP is not the solution.
[15:59:57] --- ruri has left
[16:00:15] <dthaler> (Iljitch said what I said this morning: DHCP isn't secured any more than RA is today, and it's just one more place to misconfigure something and earlier the slides stated misconfig was part of the problem, so this just makes the problem worse not better)
[16:01:08] <josoinin> Bill Fenner: Rogue DHCP servers showed up in the IETF network. We put up special filters to stop rogue DHCP servers getting to the network from the client side. Maybe this would be a possible solution.
[16:01:27] --- sam-xzq has left
[16:01:43] <josoinin> Fred: We are technically in overtime, but we have one more talk to go.
[16:02:11] <dthaler> next up: Route Injection for DHCPv6 Prefix Delegation
[16:02:17] --- jishac has left
[16:02:27] --- narten has left
[16:02:30] --- sureshk has left
[16:02:40] <dthaler> (Bill Fenner's point above is about filters in L2 switches)
[16:02:45] --- ruri has joined
[16:03:03] <dthaler> route injection with DHCP-Prefix Delegation
[16:03:20] --- sureshk has joined
[16:03:33] <iljitsch> what I said (or tried to say, may not have been successful) is that replacing RA with DHCP doesn't buy you anything on its own and with DHCPv4 the router address is a configuration option, not something inherently part sending the packet like with RA, so another opportunity to misconfigure
[16:03:42] <dthaler> relay agent between requesting router and delegating router
[16:03:59] <dthaler> (yup, I meant the same iljitsch)
[16:04:06] --- sam-xzq has joined
[16:04:37] --- bruce has left: Logged out
[16:04:49] <iljitsch> so either you run DHCPv6 on the router and you don't really have a problem or you have to do backflips to sync router addresses (which aren't as predictable on v6 as on v4) with your dhcp server config
[16:05:06] <iljitsch> of course this all happens using link locals in v6
[16:05:13] <iljitsch> (I'll shut up now)
[16:06:01] --- ruri has left
[16:06:02] <dthaler> either requesting router has to inject into a routing protocol, or else relay agent has to inject a route
[16:06:46] <dthaler> doing it from the requesting router implies delegator has some trust in requester to do the right thing
[16:07:05] <dthaler> expired survey of possible solutions: draft-stenberg-pd-route-maintenance-00
[16:07:21] <dthaler> reviewed in DHC WG in Prague
[16:07:31] <dthaler> purpose is FYI to v6ops to comment
[16:08:06] <josoinin> Kurtis: Isn't the relay agent be just a stacking mechanism for DHCP and should it be possible to have nested relay agents?
[16:08:25] --- iljitsch has left
[16:08:28] <dthaler> relay agent might lose its state if it reboots
[16:08:32] --- mg has left
[16:08:40] <josoinin> RD: Relays may be nested, but they can get out of synch with the server.
[16:08:43] <dthaler> solution may or may not involve DHCP
[16:09:15] <josoinin> Kurtis: Is there a plan what to do in a nested case.
[16:09:28] --- sam-xzq has left
[16:10:15] <josoinin> RD: In DHCPv6 there is a mechanism to select the Relay Agent to do the route injection, but it have some issues.
[16:10:47] <josoinin> ?: Why we need this? If we are using an AAA server.
[16:10:56] --- terry has left
[16:11:07] <arifumi> shin miyakawa
[16:11:14] <josoinin> RD: That is a possibility to avoid the problem all together.
[16:12:05] <josoinin> RD: Another possibility is to use a static route with an aggregatable prefix. However, this is not always possibility
[16:12:25] --- andrewsullivan has left
[16:12:26] <josoinin> Dave Thaler: This is an important problem and should be looked at the people in the v6ops.
[16:12:26] --- trond has left
[16:13:35] <josoinin> Alain Durand: The question is prefix stability.
[16:13:55] <dthaler> DT: on the question of multiple relay hops, there's two models ralph described... routing protocol (and trust) between two hops, and no routing protocol (no such trust) between two hops
[16:14:04] <josoinin> AD: If the prefix is stable, this is a larger problem, if the prefix is less stable this is easier.
[16:14:36] <dthaler> if there's no routing protocol then the upstream (towards the server) has to inject since there's no other choice. If there is a routing protocol, then downstream can inject into it. Don't need an option, just keep it simple and specify that convention
[16:15:18] <josoinin> AD: If you allow renumbering this problem is much smaller than with very stable prefixes.
[16:15:20] <David Hankins> (dthaler: ... and it all goes haywire when there is a second relay agent, or the downstream client moves and the router has no link state)
[16:15:26] --- Bob has left
[16:15:44] <dthaler> (to DH: I disagree, but I need to run to the next meeting)
[16:15:45] --- arifumi has left
[16:15:48] --- David Hankins has left
[16:15:49] --- keyajima has left
[16:15:51] --- frodek has left
[16:15:53] <josoinin> RD: DHC chairs will look where I we do the work.
[16:15:59] <josoinin> Fred: Done for today...
[16:16:12] --- josoinin has left
[16:17:38] --- rhe has left
[16:18:12] --- fred@ecotroph.net has left
[16:18:40] --- levigner has left: Replaced by new connection
[16:19:36] --- sureshk has left
[16:19:36] --- pawal has left
[16:22:37] --- dthaler has left
[16:22:40] --- BillC has left: Computer went to sleep
[16:24:02] --- FDupont has left
[16:24:30] --- itojun has left
[16:25:48] --- Bill has joined
[16:27:23] --- avri has left
[16:30:12] --- jishac has joined
[16:30:19] --- sureshk has joined
[16:30:28] --- jishac has left
[16:33:31] --- dudi has left
[16:42:03] --- Bill has left
[17:07:00] --- keyajima has joined
[17:36:41] --- keyajima has left
[17:56:59] --- sureshk has left
[19:54:04] --- sureshk has joined
[20:13:28] --- hotta has joined
[20:29:35] --- sureshk has left
[20:52:40] --- hotta has left
[21:14:29] --- sureshk has joined
[22:12:10] --- sureshk has left: Replaced by new connection