v6ops ===== o Document status Fred Baker walked through the current v6ops document status. The campus transition document has gone through two through Working Group Last Call with no comments, and the chairs and the author have decided to call it dead. Documents that have completed Working Group Last Call have been updated. If those that commented could verify that all comments are addressed, that would be appreciated. Fred pointed to some new drafts that are coming. These will potentially be future work items. o Address selection, *-addr-select-ps and *-addr-select-req, Ruri Hiromi *-addr-select problem statement have been through Working Group Last Call. Some comments where editorial, but there where also technical comments. 1.1, 2.1.4, 2.1.5, 2.1.6, 2.2.2 updated based on comments. *-addr-select requirements document had minor editorial comments and some technical comments. Ruri walked through the resolution of the technical comments. Ruri concluded with some questions about the way forward for the draft? Fred asked if there where more comments on the documents, if people where happy as is or not? No comments where made so Fred said the documents would go as they where. o Address selection, arifumi-v6ops-addr-selection-sol, Arifumi Matsumoto Arifumi Matsumoto took over and presented the solutions documents for addr-selection. A discussion followed about the use of the policy table in hosts. Alain Durand: Complexity is a problem in networks. I worry about new technology that will make the networks more complex when deploying, and I am not sure this is worth the extra cost. Fred: Are you saying it's too complex to move on? In what? Alain: We need simple things that just work. Brian Carpenter: No-one will disagree with that, but I think that there is something that we don't have standardized today. Which is a way for a site to tell all the hosts on a site what the 3484 policy is. I still think we still need to solve this problem even if it's this site. Even if it is complex large sites will want this problem solved. Arifumi: Should a problem state Itojun: The src address selection was a mistake. Everything should be decided by the routing table. Arifumi wanted more comments on the proposed solutions so that this work can be taken forward and developed as a protocol. Alain: I am sympathetic to Itojun's comments. Fred: what should we do instead. Alain, I am tempted to say : nothing. Itojun: I think that now that we are gathering real operational experience we should remove functionality. Brian: I will agree with the philosophy but IPv6 assumed multiple addresses, and we need to deal with that. I still believe this is a real problem that we need to solve. Tony: The network is complex and people tweak it here and there. You want a simple solution to complex problems, that want happen. Yes, we will have multiple prefixes. I don't understand why alain in that case have multiple prefixes in the first case. Philip Hallam-Baker: Addressing the use case you described can not be done at that network layer. You probably want to re-architect your network. ??: He just said what I wanted to say. Chris Morrow: People have big networks that they need to talk to their business partners on. The original ULAs looks like an interesting solution that. In practice it doesn't look like it might not be that east. Saying that they should use web-services instead doesn't real help. Fred asks the WG if this addresses something useful? 10 for, 10 against, 10 doesn't care. Jonne: Fred, did you say that this will continue as an individual draft? Fred: Yes, I am at a loss. o CPE issues, *-CPE-simple-security, James Woodyatt Fred asked if James could write up what would be the minimum security that should be supported by CPE. James works at Apple in the team that writes the firmware for the Airport Express, and the work is among other things based on the experiences from this work. James defined a CPE as routers for home / small office deployment. The CPE is provisioned either by the customer or the ISP. It's typically integrated with IPv5/NAT. IPv6 connectivity is acquired by tunnel or native. James walked through an analysis of what is needed as described in the draft. He pointed out that there might be some controversy regarding the 'hole-punching' protocols. Current IPv4/NAT protocols are proprietary. Itojun: I am guilty for all BSD IPv6 stacks. First comments is regarding ftp. if the client is behind your home gateway, you don't need to do anything about it. James: as long as everyone does fall-back to passive-mode. But if you do active mode, you are in trouble. Itojun: The other thing as far as I understand OS X uses ipfw from BSD. I think that you want to look at OpenBSD pf. Alain Durand: I have a few questions for you, is this draft an actual v6ops WG draft? Fred: I told him to call that. Alain: It says that you need to implement a stateful firewall. The abstract says that you might want to use these recommendations. I think it's a very bad idea to mandate a stageful firewall. We might want to deploy services where the device at home needs to be contact from the service provider, which would be blocked. I think we are going in the wrong direction with this. I think we should say that the business model for IPv6 is that connections started at home is ok, and connections started from the outside is ok by default. Fred: If I haven't' contracted this service I don't want you messing with my home. Bob: don't you want firewalls at all or are just against the default rule set? Alain I understand that the re have to e a basic security, although I am against firewalls. James: I think ti will be the case that eh products that you will find on the market will have a way to turn off all these firewalls. The question is that the draft should say about the default configuration. Hesham: On this argument, I understand both sides, but I am not sure we should mandate it one way or the other. Who is the IETF to make that mandate? It's good to explain the consequences one way or the other. James: I think tat developers needs to hear some sort of recommendations one way or the other from the IETf. Hesham: I have another question, you seems to be against a general firewall configuration protocol. Can we use the fact that no-one is implementing as a reason for not doing it? Tom Herbst: Largely agree with the draft. I don't see us releasing a product that is not compatible with the draft, we would always have a stateful firewall enabled by default. Linksys would probe what specification to use. But there is no IPv6 standard, but Kurtis: James: what we are saying is that if it works with IPv4/NAT today ti will work for IPv6. But new services etc might have issues so it might be worth sending a signal to developers of new ??: I made the comment regarding disabling of helper services that are sometimes enabled on both the internal and external interfaces of a CPE, such as a DHCP/DNS listener. Some manufacturers are not doing this and as I believe Kurtis heard in the IEPG meeting, this is a potentially significant DDoS threat, particularly if those services such as DNS accept unauthenticated service requests and provide in some cases, significantly amplified responses. In addition to the filtering capabilities, I'd like to suggest the addition of service capabilities being disabled on select interfaces, particularly helper-type services meant only for the internal net anyway such as DNS. If you'd like I can attempt some wording that may be appropriately added to your draft. I also mentioned that this reminded me of the opsec work. If you haven't already taken a look at it, here is a starting point. I think you should familiarize yourself with it if you haven't already. I think it'll be a good reference: James: I think it would be useful with some example text send to the WG. PHB: I spend a lot of time deal with Internet crime. There are some very well organized gangs our there. The more we can do by installing small amounts of intelligence to make the Internet secure it's good. But we should also look at what we can do to prevent bad traffic t leaving nets and not only coming in. James: My draft talks about this, if you feel there should be more specifies, please send text. *PHB: this was as much to the other commenters. Looking at the draft I realized that these punching-hole protocols are not authenticated. This should be a privileged operation. Tony Hain: I agree that we absolutely needs stateful fire-walling turned on by default. and we need a management protocol for this. IF I have a signaling protocol in place that let me punch-hole in these that can be integrated with signing up with the service from the provider. Itojun: It is more of IAB stuff. You need to look, at future use. If you mobile phone roams home, you can no longer get a call. JameS: As a matter fact you can. Fred: There is a T-mobile service... Itojun: You are introducing complexity. Fred: I would really like to see discussion regarding this on the v6ops mailing list. o draft-nward-v6ops-teredo-server-selection, Nathan Ward - no presentation given - Jordi: I had a mail-exchange with NAthan. He is suggested that we should have a way to do auto-discovery for the Teredo-services. Dave T: The draft proposed three ways to do server selection. The second way is the same as for 6to4, i.e anycast. I am in favor for that. IF they should be combined, I think will go back to the previous question. Protocol update or merged. o draft-hoagland-v6ops-teredoconcerns, James Hoagland (Suresh Krishnan) Based on a walk-through of security concerns with Teredo. The security concerns where then classified. Teredo allows you to open a through-hole through the security policy framework of the site and is hard to inspect. Suresh showed an example of an algorithm for deep-packet inspection of Teredo packets, but it's very complex and will be hard to do at line-rate for the firewall. Another problem is that you don't know if the packets are incoming or outgoing. ??: Dave Thaler: ?? Suresh: It's not ok to randomize a service port? DaveT: ?? Fred: Other comments? Dave T: Just a positive one. I would support adopting this as a WG item. All the recommendations are good, except the last point that we just talked about. Fred: Do we want to take this up as a WG item? rem: There is a bunch of changes to the specs, not just security. Perhaps we should go start an update of the document. Fred: We can't do protocol work here, but I am not against that. Ok, we will take this forward as wg document. o DHCP issues, Tim Chown, Stig Venaas, Ralph Droms-Handling 'Rogue' RAs. Enterprises are surprised at why they can't just use DHCPv6 but needs RA when transitioning to IPv6. Tim walked through issues with rogue RAs and how they can be caused. Iljitsch: IF you change to DHCp, you can also spoof DHCP servers. the RAs come from the router, ti's harder to spoof them. Itojun: To configure your node you will need to trust some informant. Authenticated DHCP or similar. Unauthenticated RA or DHCp is the same. Bill Fenner: I helped set-up the IETf network when a rogue RA showed up. We ended up having to set-up features to handle this. Infrastructure that support this might be one solution. o Route-injection for DHCPv6-PD, Ralph Droms Came up in the DHC wg, but wanted broader input. The problem is that when we you are doing PD you are assigning a prefix to a router. This is described in detail when there is no relay-agent is involved. It's not obvious where the routing information get's injected. Kurtis: relay-agents can be nested right? Where does the route-injection happen? Ralhpl: Extensions are planned to signal but there are some corner cases with that. ??: Dave Thaler: I encourage that that people in v6ops looks at this. As to the nested relays, there are either a routing protocol or not. You don't need actual signaling. Alain: This is an important problem to solve. The attachment point and the prefix might change over time.