6MAN Working Group - IETF 83, Paris Wednesday, Morning Session I 0900-1130, Room Name: 242AB Chairs: Bob Hinden, Brian Haberman, Ole Troan Minutes: Suresh Krishnan ====================================== Agenda Introduction, Agenda Bashing, Document Status, Chairs, 10 min. Default Address Selection for Internet Protocol version 6 (IPv6) (draft-ietf-6man-rfc3484bis) Dave Thaler 20 Neighbor Unreachability Detection is too impatient (draft-ietf-6man-impatient-nud) Erik Nordmark 10 min. Transmission of IPv6 over MS/TP Networks (draft-ietf-6man-6lobac) Kerry Lynn 15 min. Representing IPv6 Zone Identifiers in Uniform Resource Identifiers (draft-ietf-6man-uri-zoneid) Bob Hinden 10 min. IPv6 packet staining (draft-macaulay-6man-packet-stain) Tyson Macaulay 15 min. Another Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) (draft-zhou-6man-mhash-cga) Zhou Sujing 10 min. Neighbor Discovery Enhancements for DOS mititgation (draft-gashinsky-6man-v6nd-enhance) Joel Jaeggli 10 min. Fernando Gont, 50 min. A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) (draft-gont-6man-stable-privacy-addresses) Security Implications of Predictable Fragment Identification Values (draft-gont-6man-predictable-fragment-id) Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery (draft-gont-6man-nd-extension-headers) Managing the Address Generation Policy for Stateless Address Autoconfiguration in IPv6 (draft-gont-6man-managing-slaac-policy) Security and Interoperability Implications of Oversized IPv6 Header Chains (draft-gont-6man-oversized-header-chain) ============ The chairs went over the agenda and the wg document status. Slides at http://www.ietf.org/proceedings/83/slides/slides-83-6man-0.pdf There is a leadership change in the wg Ole Troan is taking over as co-chair from Brian who becomes the new INT AD (Applause for Brian) ======= Default Address Selection for Internet Protocol version 6 (IPv6) (draft-ietf-6man-rfc3484bis) Dave Thaler Slides at http://www.ietf.org/proceedings/83/slides/slides-83-6man-5.pdf Ralph Droms clarifies that there may be multiple /48 ULAs in the same site. i.e. different /48 does not necessarily mean a different site. Dave Thaler acknowledges this as correct. Dave T asked about making privacy addresses being preferred over public addresses. Wes George wanted to ask the privacy directorate. Tim Chown is fine with this for communication outside the site but not inside a site. Dave took a poll of the room. The sense of the room was in favor of this change. (Minute taker says about about 3:1) Tim wanted to know how to figure out the prefix length for the site. Dave recollected an old draft from a few years ago that used an RA to propogate this. There was not much support in the wg to take it forward Dmitry Anipko talks about a discussion in homenet about using multiple ULA prefixes and wondered that whether the /48 ULA row creation could be replaced another mechanism e.g. Route Information option. Dave thinks it is fine to do so. Wes G wants to add the newly allocated shared address space (IPv4) into the table in some form. ======= Neighbor Unreachability Detection is too impatient (draft-ietf-6man-impatient-nud) Joel Jaeggli is presenting http://www.ietf.org/proceedings/83/slides/slides-83-6man-11.pdf Dmitry is not certain about whether exponential backoff should be mandated and he wants more flexibility in setting the timeouts. Suresh Krishnan wanted the algorithm to be mandated and be the same as a DHCPv6 retransmission algorithm since it fixes some issues with RSs being lost and not retried. Lorenzo Colitti did not agree with Suresh and agreed with Dmitry about the retransmission algorithm being flexible. He thinks that the DHCPv6 algorithm sometimes causes too much traffic when there isn't a DHCPv6 server around. He also agrees that we should fix the RS to keep trying. Ralph Droms thinks that the DHCPv6 algorithm is just fine and the amount of traffic can be controlled by setting a larger maximum retransmit interval. Suresh agrees with Ralph and wants the implementations to be flexible by setting the values of the timers input to the retransmit algorithm and not the algorithm itself. ======= Transmission of IPv6 over MS/TP Networks (draft-ietf-6man-6lobac) Kerry Lynn http://www.ietf.org/proceedings/83/slides/slides-83-6man-2.pdf The chairs will hold off on proceeding (to a WGLC) until the underlying link layer definition completes its public review and is finalized Dan York is happy that this work is happening here. ======= Representing IPv6 Zone Identifiers in Uniform Resource Identifiers (draft-ietf-6man-uri-zoneid) Bob Hinden http://www.ietf.org/proceedings/83/slides/slides-83-6man-4.pdf Bill Fenner believes that it is not very likely to have a good solution in this space, but this solution is good enough. Kerry Lynn supports this work and he believes that it will be widely used in home networks (e.g. homenet). He thinks + could be used as a separator Stuart Cheshire thinks that it is important to get this work done. He does not believe the address%scope is not necessarily broken since there is no part of the host URI needs to be escaped. Jari Arkko disagrees with Kerry that home uses should need to use this URI format ever. Only "weird IETF geeks" need to learn this format. Erik Kline believes that what is typed into an URL bar does not need to be the same as what is transmitted on the wire. Dave T agrees with Stuart and he believes that anything inside "[ ]"'s in Option 2 that needs to be % encoded. He wants to make sure that anything after the % inside the "[ ]" never needs to be % encoded. Ralph agrees with Jari and prefers Option 2 with a new adjusted ABNF. Jan Zorz also agrees with Jari. Stuart (responding to Erik) talks about these URIs occurring over the wire only if they were embedded in a HTML page that got transmitted. ======= IPv6 packet staining (draft-macaulay-6man-packet-stain) Tyson Macaulay http://www.ietf.org/proceedings/83/slides/slides-83-6man-12.pdf Eric Vyncke agrees with the problem statement and he does not agree with having an extension header added on the path. He believes that it will break the MTU. He believes that MITM attacks are possible Lorenzo believes that having anything other than TCP/UDP as a next header in the IPv6 packet will get the packet dropped on the Internet since the firewalls and other middleboxes have not been updated to handle other next headers. Tyson asked Lorenzo whether the same limitations exist on an intranet. Lorenzo believed so. Wes G is also concerned about the MTU. For this to work, the network needs to support larger than standard MTU. In constrained links, such as those used in military applications, with small MTUs this may be a issue. Dan Y wants more detailed explanations about packet staining as the term is specific to the security community. ======= Another Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) (draft-zhou-6man-mhash-cga) Zhou Sujing http://www.ietf.org/proceedings/83/slides/slides-83-6man-1.pdf Jari did consider this issue during the writing of RFC4982. He believes that an increase in Sec values increases the difficulty *both* for the attackers and the defenders (address generators). He thinks that there is still some room for new algorithms in RFC4982 and he is not convinced that this is necessary. Wes G is not clear about what problem this draft is trying to solve. The presentation helped a bit but the content needs to go in the draft. Zhou said that the problem is described in 4982. Wes wanted to know what was the problem with RFC4982 that this draft is trying to fix. Jari clarifies about the general problem being a hash algorithm being broken.and needing replacement. This draft just proposes a different method than RFC4982. ======= Neighbor Discovery Enhancements for DOS mititgation (draft-gashinsky-6man-v6nd-enhance) Joel Jaeggli http://www.ietf.org/proceedings/83/slides/slides-83-6man-3.pdf Lorenzo does not believe that the value added by allowing gratuitous ND to update the ND cache under attack situations warrants changing the semantics of NUD. Joel has had some negative feedback about this idea. Lorenzo is fine with doing it as long as it is clearly stated that it could be harmful in most cases. Samita Chakrabarti has a related draft and she believes that it may solve the issue mentioned here ======= A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) (draft-gont-6man-stable-privacy-addresses) Fernando Gont http://www.ietf.org/proceedings/83/slides/slides-83-6man-6.pdf Dave clarifies that Windows 7 does not use MAC addresses by default but could be configured to do so. Eric V thought that this is an important problem to solve and he supports this draft. Dave talks about two different pieces of RFC4941 (generating temporary addresses and varying them over time) and clarifies that they can be independently applied. Suresh is not clear about the threat model that the draft is trying to solve. He believes it is important to generate a non MAC-based IID in order to spread out the address space for preventing address scanning, but does not understand why the prefix should be an input into the algorithm. Dave agreed with Suresh and provided the example of Windows 7 doing the same. Michael Richardson gives an example of a printer getting a same stable privacy address every time it connects to the home network but while still being unpredictable to an attacker. Chairs asked for the feel of the room to pursue this problem (not specific to this draft). There was general consensus to pursue the problem. ======= Security Implications of Predictable Fragment Identification Values (draft-gont-6man-predictable-fragment-id) Fernando Gont http://www.ietf.org/proceedings/83/slides/slides-83-6man-10.pdf The chairs asked about whether there is value in documenting this. Dave is fine with specifying the requirements for unpredictable ID values and letting the implementations decide how to implement them. Erik K and Suresh agreed that this was a good thing to document. Chairs to followup on ML ======= Security and Interoperability Implications of Oversized IPv6 Header Chains (draft-gont-6man-oversized-header-chain) Fernando Gont http://www.ietf.org/proceedings/83/slides/slides-83-6man-7.pdf Ole Troan stated that having arbitrary extension headers was a design feature and not a bug. Dave does not have any opinion on this yet but wants to make sure that fixed value 1280 is replaced by at least the path MTU. Eric Vyncke agrees with Dave and wants to make sure that complete header chain is present in the first fragment Ole asked about how this was different from an unknown L4 header? Fernando notes that having an unknown extension header means that you have enough information to apply a filtering policy, whereas if the full IPv6 header chain is missing, you don't have the necessary information to do it ======= Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery (draft-gont-6man-nd-extension-headers) Fernando Gont http://www.ietf.org/proceedings/83/slides/slides-83-6man-9.pdf Bob Hinden said he believes that there is no need to fragment ND packets and will issue an adoption call on the ML Eric Vyncke believes that if the previous draft is adopted, this becomes unnecessary. Fernando does not agree and gives a counter-example Andrew Yourtchenko believes that this should be done on a more general level for all application protocols. Bob said that this level of generalization is out of scope for the WG. ========= Managing the Address Generation Policy for Stateless Address Autoconfiguration in IPv6 (draft-gont-6man-managing-slaac-policy) Not presented. ========= Meeting Adjourned =========