Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08
On 2007-06-22 18:25, Fred Baker wrote: On Jun 22, 2007, at 7:38 AM, Brian E Carpenter wrote: What is out there as running code is history and words in RFCs will not change it. I think his point is that a new IPv6 implementation has just been released into the market and is not operating very well. Forget the compliance language; what he's saying is that the various IPv6 implementations around don't run in his lab as well as advertised - the running code doesn't run all that well - and he has some suggestions for Vista Service Pack 1, MacOSX Leopard, Linux, etc. How about we keep this on the technical content of what he has to say? Do you believe, and do others believe, that the problems he describes are real? Absolutely. I just don't think that delaying 2462bis has any value. Brian IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
So perhaps another question is whether it is too much to ask for more certainty (ULA-C) and less mystery (RFC4193 ULA)? So, you reckon the chance of an administrative error in ULA-C land giving two users the same prefix is less than the 2^-40 chance of a ULA clash between two users? Brian IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08
At Fri, 22 Jun 2007 09:25:13 -0700, Fred Baker [EMAIL PROTECTED] wrote: I think his point is that a new IPv6 implementation has just been released into the market and is not operating very well. Forget the compliance language; what he's saying is that the various IPv6 implementations around don't run in his lab as well as advertised - the running code doesn't run all that well - and he has some suggestions for Vista Service Pack 1, MacOSX Leopard, Linux, etc. Is that true? I've confirmed that both MacOSX(Tiger) and Linux (Fedora Core 6, kernel 2.6.18) perform DAD on both link-local and global addresses (generated from the same Mac address). I also know all BSD variants behave the same way. I don't know about Vista, but in my understand the vast majority of existing implementations actually perform DAD without an exception. JINMEI, Tatuya Communication Platform Lab. Corporate RD Center, Toshiba Corp. [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08
At Fri, 22 Jun 2007 09:05:36 -0400, Hemant Singh (shemant) [EMAIL PROTECTED] wrote: Thanks for the quick review of section 5 in our new I-D. Your reading of section 5 is correct - we have proposed both new and old implementations to always perform DAD for any unicast address. You are also correct that the gross change we have proposed over 2462bis is that old implementations MUST also not skip DAD. We stress about old implementations because if older implementations that are already deployed continue to be deployed for say, the next 5-10 years, that's not good. A software upgrade to older implementation is certainly possible. We have given a solid reason for our case - it's presented in Section 2, bullet 4 of our I-D. Please see if our reasoning is solid enough to convince IETF. I've also read that part (copied below to be very specific), but I doubt it convinces the opponents of forcing DAD in all cases. First, it is not clear which security problem this bullet tries to indicate. Also, if Host1 is assumed to be the attacker that mounts traffic hijacking and/or DoS against Host2, forcing Host2 to perform DAD doesn't help because Host1 can get the same result by simply ignoring the DAD-NS from Host1. Meanwhile, 2462bis has just entered the AUTH48 state. From what I've seen so far, I don't see the need for delaying the publication of the document due to this issue (and I'm going to complete this work just with a few minor editorial fixes). JINMEI, Tatuya Communication Platform Lab. Corporate RD Center, Toshiba Corp. [EMAIL PROTECTED] 4. The host MUST issue NS(DAD)s for all of its acquired unicast addresses except when the host interface has DupAddrDetectTransmits variable set to zero. Section 5.4 of RFC 2462 [ADDRCONF] erroneously relaxes this requirement and suffers from a security problem as illustrated by the following example: Host1 uses EUI-64 to configure a Link Local Address (LLA) using MAC1 and manually configures a Global Unicast Address (GUA) that is equal to an address configured using EUI-64 and MAC2. Host1 completes an NS(DAD) for both its LLA and GUA. Then, Host2 uses EUI-64 to configure both a LLA and a GUA using MAC2. Host2 completes an NS(DAD) for the LLA and does not send an NS(DAD) for its GUA in compliance with RFC 2462 [ADDRCONF]. Now Host1 and Host2 have the same GUA on the same link. Therefore, this exception in section 5.4 of RFC 2462 [ADDRCONF] MUST be ignored. Note that draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] refers to an extensibility concern with new implementations and states in section 5.4: Whereas this document does not invalidate such implementations, this kind of 'optimization' is NOT RECOMMENDED, and new implementations MUST NOT do that optimization. However, the security problem mentioned in this document invalidates even currently existing implementations. The Changes to draft-ietf-ipv6-rfc2462bis-08 section in this document describes the corresponding changes to draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis]. IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
On Wed, Jun 20, 2007 at 12:27:17PM +0200, Eliot Lear wrote: There are two that I can point you at, and perhaps the temporal difference would be at least amusing: * Renumbering: Threat or Menace?, Lear, Katinsky, Tharp, et al, Proceedings of the Tenth Systems Administration Conference (LISA96) * Procedures for Renumbering an IPv6 Network Without a Flag Day, Baker, Lear, Droms, RFC 4192, September, 2005. I would also add that Tim Chown has done an extensive amount of work in this space. Well, it was the 6NET team, and some documentation can be found here: http://www.6net.org/publications/deliverables/D3.6.1.pdf http://www.6net.org/publications/deliverables/D3.6.2.pdf and also Chown, T., Thompson, M., Ford, A., and S. Venaas, Things to think about when Renumbering an IPv6 network (draft-chown-v6ops-renumber-thinkabout-05.txt), March 2007. but the feeling in v6ops certainly seems to be 'we don't want to renumber, we'd rather have PI or look at id/loc longer term' so specific effort on making renumbering easier isn't really being made (in that wg at least). If your point is that you should never have to renumber, then that's a lovely way to go. It will still happen, of course, as companies merge and grow. I think IPv6 helps with the latter, but the former is still a challenge simply because topologies change. IPv6 certainly helps, but doesn't trivialise it by any means. -- Tim IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
Jeroen, Touching on just one aspect of your thoughtul post: DNS is an integral part of addressing and if we're going to move forward with ULA-C as delegated addressing then let us move forward with addressing in its entirety. So you want a disconnected address space which gets connected to the Internet? Sorry, but that more or less really implies NAT. I wouldn't call it a disconnected address space which gets connected to the Internet but rather a unique local address space which gets connected to other unique local address spaces and IMHO I don't see any implication for NAT there. Fred [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
-Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Sunday, June 24, 2007 11:59 PM To: Templin, Fred L Cc: james woodyatt; IETF IPv6 Mailing List Subject: Re: draft-ietf-ipv6-ula-central-02.txt So perhaps another question is whether it is too much to ask for more certainty (ULA-C) and less mystery (RFC4193 ULA)? So, you reckon the chance of an administrative error in ULA-C land giving two users the same prefix is less than the 2^-40 chance of a ULA clash between two users? Maybe; maybe not. But, with ULA-C, there is a (trusted?) entity that is accountable for assuring uniqueness and someone to turn to in the event of ties. There is also the concept of having sites self-generate the ULA-Cs and register them with a 3rd party entity, which puts the control in the end user's hands while still having an accountable 3rd party. BTW, this business of birthday paradox clashes has been beaten on wrt to other random address assignment paradigms too; in particular, CGAs. There, you have ~60 (?) bits for uniqueness but it has still been implied that any non-zero probability of collision is too great. Fred [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08
Let us summarize the discussion that has taken place so far and issues closed. 1. Technical content - Brian has agreed below that the problem we describe is real and we are saying our recommendation to change 2462bis I-D does fix this problem. Tatuya still has some issues with our problem, but we think till he fixes some typos in his email we cannot reply to him. This is what was sent from Tatuya that we think is text with typos: First, it is not clear which security problem this bullet tries to indicate. Also, if Host1 is assumed to be the attacker that mounts traffic hijacking and/or DoS against Host2, forcing Host2 to perform DAD doesn't help because Host1 can get the same result by simply ignoring the DAD-NS from Host1. Tatuya also needs to explain how ignoring DAD from a host is a valid implementation of the 2462 standards. Our scenario is perfectly legal within the specification. Also, note that Host1 sends out the unchallenged DAD, so routers will assume everything is OK and send their traffic to Host1 and not Host2. 2. Delay of 2462bis I-D - we'll work with you to close issues ASAP. To also reply to another email where Tatuya said: I've confirmed that both MacOSX(Tiger) and Linux (Fedora Core 6, kernel 2.6.18) perform DAD on both link-local and global addresses (generated from the same Mac address). I also know all BSD variants behave the same way. I don't know about Vista, but in my understand the vast majority of existing implementations actually perform DAD without an exception. Well, if stacks do not skip DAD, then there should be no problem with tightening up the language as we've proposed. Further, these hosts are not the only implementations out there. What about IPv6 cable modem bridges or DSL IPv6 bridges which implement an IPv6 host? These modems are deployed in a Service Provider deployment that is very strict on compliance with standards. - Hemant and Wes -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 2:38 AM To: Fred Baker (fred) Cc: Hemant Singh (shemant); ipv6@ietf.org; JINMEI Tatuya / Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 On 2007-06-22 18:25, Fred Baker wrote: On Jun 22, 2007, at 7:38 AM, Brian E Carpenter wrote: What is out there as running code is history and words in RFCs will not change it. I think his point is that a new IPv6 implementation has just been released into the market and is not operating very well. Forget the compliance language; what he's saying is that the various IPv6 implementations around don't run in his lab as well as advertised - the running code doesn't run all that well - and he has some suggestions for Vista Service Pack 1, MacOSX Leopard, Linux, etc. How about we keep this on the technical content of what he has to say? Do you believe, and do others believe, that the problems he describes are real? Absolutely. I just don't think that delaying 2462bis has any value. Brian IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Templin, Fred L wrote: Jeroen, Touching on just one aspect of your thoughtul post: DNS is an integral part of addressing and if we're going to move forward with ULA-C as delegated addressing then let us move forward with addressing in its entirety. So you want a disconnected address space which gets connected to the Internet? Sorry, but that more or less really implies NAT. I wouldn't call it a disconnected address space which gets connected to the Internet but rather a unique local address space which gets connected to other unique local address spaces and IMHO I don't see any implication for NAT there. If you are only connecting to another ULA network, then why would one ever need NS entries in ip6.arpa for this space? The whole story is about having NS entries in the ip6.arpa tree for the delegation. When you have a delegation in the Internet ip6.arpa tree, you also need to query them one way or the other and thus you are connecting your ULA-based network to that Internet. Also, people will the notice that they can use reverses from the Internet, at one point or another will also want to use SIP or various other protocols and thus end up using the Internet, and there are two ways to do that: NAT it or simply announce the ULA prefix, renumbering to a PI block is of course not an option here. As such, what is the 'local' part again, how local is it really? And how is ULA-C then different from PI? Why bother people with this ULA-C thing when they really need PI in the first place? Which they can already get for $100/year from ARIN and which will be guaranteed unique, just like all other address space from the RIR's. Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
-Original Message- From: Jeroen Massar [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 8:27 AM To: Templin, Fred L Cc: bill fumerola; ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt Templin, Fred L wrote: Jeroen, Touching on just one aspect of your thoughtul post: DNS is an integral part of addressing and if we're going to move forward with ULA-C as delegated addressing then let us move forward with addressing in its entirety. So you want a disconnected address space which gets connected to the Internet? Sorry, but that more or less really implies NAT. I wouldn't call it a disconnected address space which gets connected to the Internet but rather a unique local address space which gets connected to other unique local address spaces and IMHO I don't see any implication for NAT there. If you are only connecting to another ULA network, then why would one ever need NS entries in ip6.arpa for this space? To aid in connecting to another ULA network. The whole story is about having NS entries in the ip6.arpa tree for the delegation. When you have a delegation in the Internet ip6.arpa tree, you also need to query them one way or the other and thus you are connecting your ULA-based network to that Internet. Connecting to the IPv4 Internet in order to query the ip6.arpa tree should work fine; right? Also, people will the notice that they can use reverses from the Internet, at one point or another will also want to use SIP or various other protocols and thus end up using the Internet, and there are two ways to do that: NAT it or simply announce the ULA prefix, renumbering to a PI block is of course not an option here. I don't see how that follows, and I do not want IPv6 NAT. As such, what is the 'local' part again, how local is it really? And how is ULA-C then different from PI? Why bother people with this ULA-C thing when they really need PI in the first place? Which they can already get for $100/year from ARIN and which will be guaranteed unique, just like all other address space from the RIR's. IMHO, a site can be as large as a major corporation's private Intranet or as small as my laptop, and I don't want to have to pay $100/yr just to connect my laptop to other sites. Fred [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
BTW, this business of birthday paradox clashes has been beaten on wrt to other random address assignment paradigms too; in particular, CGAs. There, you have ~60 (?) bits for uniqueness but it has still been implied that any non-zero probability of collision is too great. Fred [EMAIL PROTECTED] In practical terms, zero probability is not to be found in this universe. People who demand zero probability for anything need to be educated. 2^-40 probability is as close as you're going to get. Really! -- George Mitchell IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Templin, Fred L wrote: [..] If you are only connecting to another ULA network, then why would one ever need NS entries in ip6.arpa for this space? To aid in connecting to another ULA network. So you are able to setup routing between those two sites, but feeding them with NS entries for your reverse is too hard? IMHO the latter is actually much easier, just find the DNS servers for the site, presto. The whole story is about having NS entries in the ip6.arpa tree for the delegation. When you have a delegation in the Internet ip6.arpa tree, you also need to query them one way or the other and thus you are connecting your ULA-based network to that Internet. Connecting to the IPv4 Internet in order to query the ip6.arpa tree should work fine; right? Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't matter, you have a dependency on the Internet. As such you are not working dis-connected from the Internet and you have a dependency on it. I was under the impression, clearly wrongly, that people wanted ULA so they where completely independent of the Internet with no ties there whatsoever. Also, people will the notice that they can use reverses from the Internet, at one point or another will also want to use SIP or various other protocols and thus end up using the Internet, and there are two ways to do that: NAT it or simply announce the ULA prefix, renumbering to a PI block is of course not an option here. I don't see how that follows, and I do not want IPv6 NAT. There are a lot of networks that only where local and used RFC1918 because of this, then at a certain point oeh we merge, and they had to connect to another network (which then clashed and also caused NAT and other weird things but that is another point). That 'other' network sometimes was the Internet, as oeh it is handy that we can access google/wikipedia/etc and instead of renumbering, lets NAT, as that is easy quick and 'cheap', they forget though how much pain it is in the long run. As such, what is the 'local' part again, how local is it really? And how is ULA-C then different from PI? Why bother people with this ULA-C thing when they really need PI in the first place? Which they can already get for $100/year from ARIN and which will be guaranteed unique, just like all other address space from the RIR's. IMHO, a site can be as large as a major corporation's private Intranet or as small as my laptop, and I don't want to have to pay $100/yr just to connect my laptop to other sites. A site is a network of computers with a single administration, this can mean indeed a major corporation (who maybe even require multiple /48's which is why rfc4193 is a bit off to cover those cases) If you want to have a /48 for your laptop, simply use ULA (RFC4193) those are free. Or are you simply wanting to have your own IP addresses, setting up firewalling etc because you have a laptop (or Winnebago filled with servers) and carrying it around globally through various buildings and making other networks accept your /48 AND force them to connect to the Internet to be able to resolve your reverse? Most likely anyway when you connect your laptop to another site they will be providing you with an IP address anyway from their site prefix. Can you clarify the use case you are sketching here a lot more as I really want to know what actual use case is actually useful that ULA-C solves, what PI doesn't solve (Drawings + text help). Especially now that the folks who 'want/need' ULA-C do want to have reverse DNS available from the Internet, while they want to be local in the first place. All those cases can be covered perfectly fine by PI. Or is it just that folks see ULA-C as 'very cheap PI space'? Greets, Jeroen signature.asc Description: OpenPGP digital signature IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
Jeroen, -Original Message- From: Jeroen Massar [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 9:00 AM To: Templin, Fred L Cc: bill fumerola; ipv6@ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt Templin, Fred L wrote: [..] If you are only connecting to another ULA network, then why would one ever need NS entries in ip6.arpa for this space? To aid in connecting to another ULA network. So you are able to setup routing between those two sites, but feeding them with NS entries for your reverse is too hard? IMHO the latter is actually much easier, just find the DNS servers for the site, presto. I didn't quite understand this, but I am not a DNS expert. The whole story is about having NS entries in the ip6.arpa tree for the delegation. When you have a delegation in the Internet ip6.arpa tree, you also need to query them one way or the other and thus you are connecting your ULA-based network to that Internet. Connecting to the IPv4 Internet in order to query the ip6.arpa tree should work fine; right? Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't matter, you have a dependency on the Internet. As such you are not working dis-connected from the Internet and you have a dependency on it. Only when you want to connect to another site. I was under the impression, clearly wrongly, that people wanted ULA so they where completely independent of the Internet with no ties there whatsoever. I can't speak for the use cases other people might have in mind. Also, people will the notice that they can use reverses from the Internet, at one point or another will also want to use SIP or various other protocols and thus end up using the Internet, and there are two ways to do that: NAT it or simply announce the ULA prefix, renumbering to a PI block is of course not an option here. I don't see how that follows, and I do not want IPv6 NAT. There are a lot of networks that only where local and used RFC1918 because of this, then at a certain point oeh we merge, and they had to connect to another network (which then clashed and also caused NAT and other weird things but that is another point). That 'other' network sometimes was the Internet, as oeh it is handy that we can access google/wikipedia/etc and instead of renumbering, lets NAT, as that is easy quick and 'cheap', they forget though how much pain it is in the long run. Again, *no* NAT'ing of IPv6. As such, what is the 'local' part again, how local is it really? And how is ULA-C then different from PI? Why bother people with this ULA-C thing when they really need PI in the first place? Which they can already get for $100/year from ARIN and which will be guaranteed unique, just like all other address space from the RIR's. IMHO, a site can be as large as a major corporation's private Intranet or as small as my laptop, and I don't want to have to pay $100/yr just to connect my laptop to other sites. A site is a network of computers with a single administration, A laptop fits this description. Think of one running some of this new virtualization support whereby there may be many virtual machines connected up by virtual networks running within the laptop. (Actually, folks like IBM were doing this new virtualization on their mainframes back in the 70's...) this can mean indeed a major corporation (who maybe even require multiple /48's which is why rfc4193 is a bit off to cover those cases) If you want to have a /48 for your laptop, simply use ULA (RFC4193) those are free. RFC4193 ULA is good, but could be better. However remote the possibility of collisions, IMHO there would still be value in having a 3rd-party mechanism to avoid duplicate assignments and/or de-conflict duplicates. Or are you simply wanting to have your own IP addresses, setting up firewalling etc because you have a laptop (or Winnebago filled with servers) and carrying it around globally through various buildings and making other networks accept your /48 AND force them to connect to the Internet to be able to resolve your reverse? I don't quite understand this, but I want to be able to drop my laptop down in whatever visited network and have it connect to other sites w/o having to manually configure explicit VPNs. Most likely anyway when you connect your laptop to another site they will be providing you with an IP address anyway from their site prefix. One use I could see for that is if you needed a care-of address such as used for MIPv6. But, that gets off onto a completely different line of discussion. Can you clarify the use case you are sketching here a lot more as I really want to know what actual use case is actually useful that ULA-C solves, what PI doesn't solve (Drawings + text help). Especially now that the folks who 'want/need' ULA-C do want to have reverse DNS available from the Internet, while they
RE: draft-ietf-ipv6-ula-central-02.txt
But can't you do that perfectly well with PI or PA, firewall it as appropriate and use regular DNS? Even if two unique local address spaces were carved out of PI or PA, restricted from public access, and allowed to intercommunicate as a sort of unauthenticated unencrypted private network using public DNS it still seems that either PI or PA would suit the need very functionally. If it's all about renumbering avoidance, and we made an acronymn for Provider Independent space I suspect we might refer to it as PI. -Original Message- From: Templin, Fred L [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 9:17 AM To: Jeroen Massar; bill fumerola Cc: ipv6@ietf.org Subject: RE: draft-ietf-ipv6-ula-central-02.txt Jeroen, Touching on just one aspect of your thoughtul post: DNS is an integral part of addressing and if we're going to move forward with ULA-C as delegated addressing then let us move forward with addressing in its entirety. So you want a disconnected address space which gets connected to the Internet? Sorry, but that more or less really implies NAT. I wouldn't call it a disconnected address space which gets connected to the Internet but rather a unique local address space which gets connected to other unique local address spaces and IMHO I don't see any implication for NAT there. Fred [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
draft-ietf-ipv6-deprecate-01-01-candidate-02
Hi all, Apologies for the delay on this update; real life has been intruding with great regularity. The change-log reads: 01-candidate-02 Moved description of traffic amplification to Section 1, and inserted a corresponding cross-reference in Section 5. Strengthened the language in Section 4.2 along the lines suggested by Thomas Narten. Small typos corrected. Added a further sentence in Section 4.1 intended to act as further encouragement for operators to implement [RFC3704]. I still have my doubts about the practical usefulness of a standards document attempting to dictate operational behaviour using normative language, but since my doubts aren't widely shared I am happy to throw them to the side. Unified diff follows; new candidate text is attached. If I've missed any other updates requested by people, please let me know and I promise a more rapid turn-around for subsequent candidates. Alternatively, if people tell me to submit this as -01, I will do so with all due alacrity. Thanks, Joe --- draft-ietf-ipv6-deprecate-rh0-01-01.unpg2007-06-25 12:52:59.0 -0400 +++ draft-ietf-ipv6-deprecate-rh0-01.unpg 2007-06-25 12:51:22.0 -0400 @@ -11,7 +11,7 @@ Deprecation of Type 0 Routing Headers in IPv6 - draft-ietf-ipv6-deprecate-rh0-01-candidate-01 + draft-ietf-ipv6-deprecate-rh0-01-candidate-02 Status of this Memo @@ -45,10 +45,11 @@ Abstract The functionality provided by IPv6's Type 0 Routing Header can be - exploited in order to achieve packet amplification for the purposes - of generating denial-of-service traffic. This document updates the - IPv6 specification to deprecate the use of IPv6 Type 0 Routing - Headers, in the light of the severity of this security concern. + exploited in order to achieve traffic amplification over a remote + path for the purposes of generating denial-of-service traffic. This + document updates the IPv6 specification to deprecate the use of IPv6 + Type 0 Routing Headers, in the light of the severity of this security + concern. This document updates RFC 2460 and RFC 4294. @@ -80,11 +81,29 @@ also defined. Type 0 Routing Headers are referred to as RH0 in this document. - The functionality provided by IPv6's Type 0 Routing Header can be - exploited in order to achieve packet amplification for the purposes - of generating denial-of-service traffic. This document updates the - IPv6 specification to deprecate the use of IPv6 Type 0 Routing - Headers, in the light of the severity of this security concern. + A single RH0 may contain multiple waypoint addresses, and the same + address may be included more than once in the same RH0. This allows + a packet to be constructed such that it will oscillate between two + RH0-processing hosts or routers many times. This allows a stream of + packets from an attacker to be amplified along the path between two + remote routers, which could be used to cause congestion along + arbitrary remote paths and hence act as a denial-of-service + mechanism. 88-fold amplification has been demonstrated using this + technique [CanSecWest07]. + + This attack is particularly serious in that it affects the entire + path between the two exploited nodes, not only the nodes themselves + or their local networks. Analogous functionality may be found in the + IPv4 source route option, but the opportunities for abuse are greater + with RH0 due to the ability to specify many more waypoints in each + packet. + + The severity of the threat is considered to be sufficient to warrant + deprecation of RH0 entirely. This has the unfortunate side-effect + that benign use cases for RH0 are eliminated along with the potential + security hazards; such applications may be facilitated in the future + by new routing header specifications which do not suffer from RH0's + problems. This document updates [RFC2460] and [RFC4294]. @@ -129,21 +148,27 @@ described in [CanSecWest07] can be mitigated using ingress filtering, as recommended in [RFC2827] and [RFC3704]. + A site security policy intended to protect against attacks using RH0 + SHOULD include the implementation of ingress filtering at the site + border. + 4.2. Firewall Policy + Blocking all IPv6 packets which carry Routing Headers (rather than + specifically blocking type 0, and permitting other types) has very + serious implications for the future development of IPv6. If even a + small percentage of deployed firewalls block other types of routing + headers by default, it will become impossible in practice to extend + IPv6 routing headers. For example, Mobile IPv6 [RFC3775] relies upon + a type-2 RH; wide-scale, indescriminate blocking of Routing Headers + will make Mobile IPv6 undeployable. + Firewall policy intended to protect against packets containing
Re: draft-ietf-ipv6-ula-central-02.txt
Templin, Fred L wrote:
[..]
Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't
matter, you have a dependency on the Internet. As such you are not
working dis-connected from the Internet and you have a
dependency on it.
Only when you want to connect to another site.
Thus the moment you are connecting to another site you are forcing one
to also connect to the Internet.
[..]
Again, *no* NAT'ing of IPv6.
How are you going to use ULA-C addresses as a source and then connect to
hosts on the global Internet?
[..]
A laptop fits this description. Think of one running some
of this new virtualization support whereby there may be
many virtual machines connected up by virtual networks
running within the laptop. (Actually, folks like IBM were
doing this new virtualization on their mainframes back
in the 70's...)
I have one of those sweet laptops and I have 3 OS's running at the same
time most of the time. I use RFC1918 and simply randomly picked
172.17.123.0/24 which has (upto now :) never collided with the networks
that I visited. ULA (RFC4193) would have that same property. I have to
note that I have to NAT that address space to the network I am at, who
only give me 1 single IP address most of the time (could use bridging
and prolly ask for more addresses per DHCP of course). Having them route
my prefix to me though everytime I walk into a Starbucks or a hotel etc
is really never ever going to happen. There is no this is my prefix
route my traffic here protocol (at least yet). Also no single network
operator will ever accept such a protocol as it is their network, not
that of the visitor to control. Viruses and {cr|h}ackers would love it I
guess.
When you are in the position to negotiate the routing part, then having
them turn up DNS, which has to happen for both forward (how else are
they going to locate your host) and reverse hosts is very doable.
This then nullifies the whole requirement of having NS pointers to your
servers, which have to have internet-connected and static addresses
unless you want to update them all the time, which for sure makes the
RIR happy who definitely want to have more cash then for doing that.
Or are your requiring sites you visit to have Internet connectivity as
you only have your servers (forward + reverse) on the Internet?
this can
mean indeed a major corporation (who maybe even require multiple /48's
which is why rfc4193 is a bit off to cover those cases)
If you want to have a /48 for your laptop, simply use ULA (RFC4193)
those are free.
RFC4193 ULA is good, but could be better. However remote the
possibility of collisions, IMHO there would still be value in
having a 3rd-party mechanism to avoid duplicate assignments
and/or de-conflict duplicates.
It exists: PI space. Get it at ARIN today: $100/year
Which if you have such a high reliability requirement for non-clashes is
very cheap and gives you the possibility to do reverse DNS and even
route it on the global internet, just in case they provide you with
transit at the site you happen to come along.
Or are you simply wanting to have your own IP
addresses,
setting up firewalling etc because you have a laptop (or Winnebago
filled with servers) and carrying it around globally through various
buildings and making other networks accept your /48 AND force them to
connect to the Internet to be able to resolve your reverse?
I don't quite understand this, but I want to be able to
drop my laptop down in whatever visited network and have
it connect to other sites w/o having to manually configure
explicit VPNs.
How are you 'automatically' telling the network to route packets for
'your prefix' to your device? See above.
Most likely anyway when you connect your laptop to another site they
will be providing you with an IP address anyway from their
site prefix.
One use I could see for that is if you needed a care-of
address such as used for MIPv6.
Care-of-addresses are simply the address you get per DHCP/RA.
But, that gets off onto a completely different line of discussion.
It also has nothing to do with connecting to sites.
Can you clarify the use case you are sketching here a lot more as I
really want to know what actual use case is actually useful that ULA-C
solves, what PI doesn't solve (Drawings + text help). Especially now
that the folks who 'want/need' ULA-C do want to have reverse DNS
available from the Internet, while they want to be local in
the first place.
I already gave my use-case in:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html
As I mentioned above, how are the routing protocols automatically
trusting that you own the prefix, or for that matter finding each other
in the first place. This will involve a protocol that can handle this.
When such a protocol exists you can also have it handle your reverse DNS
setup.
I fully agree that there is a need for Unique Addresses, and these
exist already, it is called: PI.
Re: draft-ietf-ipv6-ula-central-02.txt
Jeroen Massar wrote: As such, what is the 'local' part again, how local is it really? And how is ULA-C then different from PI? Why bother people with this ULA-C thing when they really need PI in the first place? Which they can already get for $100/year from ARIN and which will be guaranteed unique, just like all other address space from the RIR's. Jeroen, PI space is *not* available, *at any price*, to small sites. ARIN (and generally, RIR) policy for the allocation of PI space (space assigned directly from the RIR to end sites that they can announce into the DFZ) is based on the assumption that any such space, once allocated, can add an additional route to the BGP table of hundreds of thousands of routers across the globe. Therefore, such policy must be conservative in handing out such blocks. A need has been put forward for registered unique IPv6 address space that is not intended to be advertised into the DFZ. One viable way to meet this need is with ULA-C. Another way would be with a new class of private PI space out of a dedicated block that DFZ operators would not accept routes from. If you'd like to advocate we create RIR policy for private PI space instead of doing ULA-C, please put forth your arguments for why it would be better. Or, if you think that the need presented is too insignificant to be worth standardizing draft-ietf-ipv6-ula-central-02.txt for, fine. But please quit telling us that we don't need ULA-C because we can just go get PI space today. -Scott IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: What is an IPv6 fragment?
Vishwas Manral wrote: Hi Suresh/ Vlad, For SIIT the fragment header is used to signal the ability to fragment, it does not state it is a fragment itself. First, this only happens when the IPv4 host does not support path mtu discovery (DF bit is 0). In this case, inserting a fragment header at the translator in essence performs the fragmentation that was requested by the sender. I just so happens that in this case the fragment might have offset and M flag set to 0. A fragment with offset 0 and M flag 0 is just treated as the ONLY fragment. No harm don But there are different policies for fragments, including some that drop fragments. It is not the correct behavior, I feel the definition of a fragment should be clarified. Now you are getting in policies outside of the definition. The definition does not have to encompass all eventual uses. Otherwise we'll be updating a lot more specs. -vlad IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
On 25 Jun 2007, at 1:17pm, Scott Leibrand wrote: [...] PI space is *not* available, *at any price*, to small sites. How many of these sites that are too small to qualify for PI space are likely to have such a large number of inter-site connections that there is a credible risk that there will be an address clash? Regards, Leo Vegoda IANA Numbers Liaison IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Leo Vegoda wrote: On 25 Jun 2007, at 1:17pm, Scott Leibrand wrote: PI space is *not* available, *at any price*, to small sites. How many of these sites that are too small to qualify for PI space are likely to have such a large number of inter-site connections that there is a credible risk that there will be an address clash? I don't know. I do suspect, however, that the main benefit of ULA-C over ULA-L will be the ability to resolve DNS, rather than the additional assurance of uniqueness. Even with a relatively small number of inter-site connections, it is much easier to have your DNS resolvers (which presumably have a public IP address as well as a ULA one) walk the DNS tree rather than manually configuring them to slave off of each other site's DNS servers. (I would compare it to doing all your inter-site routing with static routes instead of using a routing protocol.) -Scott IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
On Jun 25, 2007, at 09:33, Templin, Fred L wrote: I already gave my use-case in: http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html The use-case I am most interested in is Mobile Ad-Hoc Networks (MANETs) in which two or more MANETs can merge (e.g., due to mobility). If each MANET used ULA-C's, then they could inject each others' prefixes into their IGPs with no opportunity for collision. If each MANET instead used RFC4193 ULAs, then they could *probably* still inject each others' prefixes. But, however small the risk of collision, RFC4193 ULAs still have one drawback that ULA-C's do not - uncertainty. So perhaps another question is whether it is too much to ask for more certainty (ULA-C) and less mystery (RFC4193 ULA)? The no opportunity for collision thing is really the question here, as Brian E. Carpenter said in http://www1.ietf.org/mail-archive/web/ ipv6/current/msg07834.html and others have said elsewhere. Most of the pushback is directed at this claim that central registration has some hope for mitigating an already *epsilon* risk of collision. I don't think simply reiterating the claim is an appropriate response to the legitimate rebuttal it's received. An additional claim we've seen is that ULA-C should offer reverse delegations from ip6.arpa in the public DNS horizon, whereas ULA-L (straight RFC 4193) does not. Your use case does not seem to me to support the argument for ULA-C, but actually demonstrates its weakness. When two MANET merge by exchanging ULA prefixes (let's forget about ULA-C vs. ULA-L for now, because the name resolution problem is common to both), then their DNS horizons must be merged as well. The networks are *ad-hoc*, so they do not have name servers provisioned with globally reachable unicast addresses. If they did, then they wouldn't be *ad-hoc* mobile networks. They'd be *provisioned* mobile networks. So, the two MANET may have name servers, but if so, then they're only reachable at ULA addresses and they contain records that are only usable inside the merged MANET. What you need to do is exchange the reverse delegations for the ULA prefixes at the same time you exchange the prefixes. You already have to merge two private DNS horizons into a single private DNS horizon. Asking for help from the public DNS horizon seems like a very questionable thing to propose. Looking up the records containing ULA-C addresses for the peer MANET name servers in the public DNS horizon is prohibitively expensive for the usage scenario you're proposing. Let me illustrate. Who will operate the authoritative name servers for the global public 0.0.c.f.ip6.arpa domain? How will mobile *ad-hoc* networks get NS records inserted into that zone? How are they changed? How will registrations be released and made available for reuse? Do registrations expire if you don't pay your bills on time? Perhaps most importantly, how do MANET remain *ad-hoc* given such provisioning requirements? All those questions seem to be pressing and unanswered. (p.s. I have long contended with my colleague, Stuart Cheshire, that Multicast DNS could use to be extended to support organization-local scope multicast, precisely to support ad-hoc ULA-addressed internets. Alas, there hasn't been much perception around here of any burning need to do it-- the subject of rendezvous points always comes up, and nobody has time to come up to speed on all the latest technical aspects of the problem. Perhaps additional energy should be expended there toward those ends?) -- james woodyatt [EMAIL PROTECTED] member of technical staff, communications engineering IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: What is an IPv6 fragment?
Hi Vlad, Thanks a lot for your clarification, maybe I am unclear. I am attaching a document I have attached, just have a look. First, this only happens when the IPv4 host does not support path mtu discovery (DF bit is 0). In this case, inserting a fragment header at the translator in essence performs the fragmentation that was requested by the sender. I just so happens that in this case the fragment might have offset and M flag set to 0. There are 2 sides of the problem. The first is that different protocols use different definition of a fragment, which needs to be clarified, because some assumption by a protocol may not work in many cases due to the specification clarity. The second part is the use of different policies for fragments. The idea I am stating is that one spec uses the Fragment header to just signal its ability to perform fragmentation, while others specs(AH ESP for one) clearly lay down a differnet way for identifying an IPv6 fragment and its subsequent treatment. As there are different policies for fragments, the signaling may not work in many cases(no I am not talking about policies but the clarification of the term Fragment - example a Fragment with M = 0 and Offset = 0 should be treated as a non fragmented packet). I do not see any problem in clarifying exactly what an IPv6 fragment is so that we can have a consistent set of specs as well as implementations. Now you are getting in policies outside of the definition. The definition does not have to encompass all eventual uses. Otherwise we'll be updating a lot more specs. No, I am talking about specs too besides practical network scenarios. If we see a problem in a spec I do not see a reason we should hesitate in fixing the problems (and its not unprecedented either). Thanks, Vishwas On 6/25/07, Vlad Yasevich [EMAIL PROTECTED] wrote: Vishwas Manral wrote: Hi Suresh/ Vlad, For SIIT the fragment header is used to signal the ability to fragment, it does not state it is a fragment itself. First, this only happens when the IPv4 host does not support path mtu discovery (DF bit is 0). In this case, inserting a fragment header at the translator in essence performs the fragmentation that was requested by the sender. I just so happens that in this case the fragment might have offset and M flag set to 0. A fragment with offset 0 and M flag 0 is just treated as the ONLY fragment. No harm don But there are different policies for fragments, including some that drop fragments. It is not the correct behavior, I feel the definition of a fragment should be clarified. Now you are getting in policies outside of the definition. The definition does not have to encompass all eventual uses. Otherwise we'll be updating a lot more specs. -vlad Network Working Group V. Manral Internet-Draft IP Infusion Expires: December 25, 2007 June 26, 2007 IPv6 Fragments and treatment of Tiny fragments draft-manral-ipv6-fragments-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 25, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract [RFC2460] defines an IPv6 header called Fragment Header, which is identified by a Next Header value of 44 in the immediately preceding header. This document clarifies the definition of an IPv6 fragment Manral, et al. Expires December 25, 2007[Page 1] Internet-Draft IPv6 Fragments June 2007 as well as defines the treatment of what consititues a tiny IPv6 Fragment. Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 [RFC2119].
Re: What is an IPv6 fragment?
Hi Vishwas I think you are reading too much into this, thus the issue is confused. Vishwas Manral wrote: Hi Vlad, Thanks a lot for your clarification, maybe I am unclear. I am attaching a document I have attached, just have a look. First, this only happens when the IPv4 host does not support path mtu discovery (DF bit is 0). In this case, inserting a fragment header at the translator in essence performs the fragmentation that was requested by the sender. I just so happens that in this case the fragment might have offset and M flag set to 0. There are 2 sides of the problem. The first is that different protocols use different definition of a fragment, which needs to be clarified, because some assumption by a protocol may not work in many cases due to the specification clarity. The second part is the use of different policies for fragments. The idea I am stating is that one spec uses the Fragment header to just signal its ability to perform fragmentation, No, it does in fact fragment the packets. It just so happens that it may result in a single fragment. The behavior here is not much different from some node on path returning ICMP Too Big with MTU less the 1280. The fragment is there to make translators work so that the translation of the DF bit is not lost while the IPv4 packet is traversing an IPv6 network. while others specs(AH ESP for one) clearly lay down a differnet way for identifying an IPv6 fragment and its subsequent treatment. As there are different policies for fragments, the signaling may not work in many cases(no I am not talking about policies but the clarification of the term Fragment - example a Fragment with M = 0 and Offset = 0 should be treated as a non fragmented packet). I do not see any problem in clarifying exactly what an IPv6 fragment is so that we can have a consistent set of specs as well as implementations. Now you are getting in policies outside of the definition. The definition does not have to encompass all eventual uses. Otherwise we'll be updating a lot more specs. No, I am talking about specs too besides practical network scenarios. If we see a problem in a spec I do not see a reason we should hesitate in fixing the problems (and its not unprecedented either). Ok, so are you concerned with what IPSec considers a fragment and how individual IPSec policies treat those fragments? 2. IPv6 Fragment The IPv6 specification [RFC2460] defines a fragment header as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved| Fragment Offset|Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Identifies the initial header type of the Fragmentable Part of the original packet (defined below). Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.]. Reserved 8-bit reserved field. Initialized to zero for transmission; ignored on reception. Fragment Offset 13-bit unsigned integer. The offset, in 8-octet units, of the data following this header, relative to the start of the Fragmentable Part of the original packet. Res 2-bit reserved field. Initialized to zero for transmission; ignored on reception. M flag 1 = more fragments; 0 = last fragment. Identification 32 bits is used for facilitating each fragment is correctly reassembled at the receiver. An IPv6 fragment is defined to be an IPv6 packet, which contains the IPv6 Fragment header as described above, having either the More flag or the Fragment Offset set to have a non 0 value. Well, that's not quite right, since the middle fragments will have both a non-zero offset and More flag set. What the statement from you draft implies is that one or the other may be omitted, which is not the case. Manral, et al. Expires December 25, 2007[Page 3] Internet-Draft IPv6 Fragments June 2007 In turn if an IPv6 packet contains a fragment header, with both the More flag as well as the Fragment Offset fields set to, it is treated exactly like an IPv6 packet without the Fragment header. This seems like a clarification that might be useful. -vlad IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08
Hi Tatuya, Please see in line below with hs. -Original Message- From: JINMEI Tatuya / [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 11:28 AM To: Hemant Singh (shemant) Cc: Brian E Carpenter; Fred Baker (fred); ipv6@ietf.org Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 At Mon, 25 Jun 2007 10:45:35 -0400, Hemant Singh (shemant) [EMAIL PROTECTED] wrote: Let us summarize the discussion that has taken place so far and issues closed. 1. Technical content - Brian has agreed below that the problem we describe is real and we are saying our recommendation to change 2462bis I-D does fix this problem. Tatuya still has some issues with our problem, but we think till he fixes some typos in his email we cannot reply to him. This is what was sent from Tatuya that we think is text with typos: First, it is not clear which security problem this bullet tries to indicate. Also, if Host1 is assumed to be the attacker that mounts traffic hijacking and/or DoS against Host2, forcing Host2 to perform DAD doesn't help because Host1 can get the same result by simply ignoring the DAD-NS from Host1. Yeah, there was a typo. It should actually be: First, it is not clear which security problem this bullet tries to indicate. hs The problem we refer to is the fact that Host1 and Host2 have the same GUA on the same link! This is an obvious problem because Host1 is able to get an authoritative (because Host1 issued an unchallenged DAD for GUA) GUA that is also later assigned to Host2. Note that Host1 does not need an incorrectly implemented or hacked up IPv6 stack to reach this problem scenario - the problem arises with a fully compliant IPv6 host stack on Host1 and Host2 using only the interface exported to an end user. If Host2 was NOT allowed to skip DAD, then Host2 will issue a NS(DAD) for GUA and Host1 being a compliant host would reply with an NA saying I have this GUA. The net result is that traffic that should have gone to Host2, goes to Host1 instead - why is this not a security problem? Also, if Host1 is assumed to be the attacker that mounts traffic hijacking and/or DoS against Host2, forcing Host2 to perform DAD doesn't help because Host1 can get the same result by simply ignoring the DAD-NS from Host2. (i.e., replace the final Host1 with Host2) hs The second problem case, when Host1 is a rogue and not compliant with IPv6 standards, sure Host1 can ignore the DAD-NS from Host2 but the IPv6 router on the link MAY catch this duplicate since the router has also seen this NS(DAD). We envision that the router logs an error message. Again, in our previous case above, if Host2 had skipped NS(DAD) then the router would not catch this problem. Tatuya also needs to explain how ignoring DAD from a host is a valid implementation of the 2462 standards. Why should I? I interpreted the bullet as describing Host1 was an attacker, so it would do anything (whether it's valid or not wrt standards) to make the attack succeed. hs OK, now that we read your reply with the typo fixed, we agree with you here. It's because Host1 is a rogue, this host will ignore the NS(DAD) from Host2 for GUA. In any event, the main point is that it's not clear (to me) which security problem this draft tries to explain (and how the change in the specification helps solve or mitigate the problem). Well, if stacks do not skip DAD, then there should be no problem with tightening up the language as we've proposed. I'd rather say that *if* stacks do not skip DAD, then there should be no problem with leaving the current text as is (remember new implementations won't skip DAD, so leaving the text won't cause a problem in the future either). And if so, I'd rather keep it since I don't see any value in modifying text that has been fully reviewed and does not actually have any problem. hs Do you acknowledge the problem we describe above? Since we realize that 2462bis I-D is in AUTH48 state, a change like this may require IETF-wide review and that would further delay 2462bis becoming an RFC. But then where do we put changes like ours? Our I-D is at the beginning of the process, so it may be an appropriate place for this and any further changes if they can't make it into 2462bis. A note to the IPv6 WG chairs. Please add our I-D to the agenda for the July IETF meeting. Thanks, Hemant and Wes IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
RE: draft-ietf-ipv6-ula-central-02.txt
Jeroen,
I don't quite understand some of your points, so I am
not going to try to make conjectures about those. But,
I will respond to what I can below:
-Original Message-
From: Jeroen Massar [mailto:[EMAIL PROTECTED]
Sent: Monday, June 25, 2007 10:09 AM
To: Templin, Fred L
Cc: bill fumerola; ipv6@ietf.org
Subject: Re: draft-ietf-ipv6-ula-central-02.txt
Templin, Fred L wrote:
[..]
Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't
matter, you have a dependency on the Internet. As such you are not
working dis-connected from the Internet and you have a
dependency on it.
Only when you want to connect to another site.
Thus the moment you are connecting to another site you are forcing one
to also connect to the Internet.
The way I envision for a site to connect to another site
is via establishing one or more links between the two sites.
Having the two sites come in physical proximity with each
other (e.g., due to mobility) is one way. Establishing
tunnels between them across the Internet is another way.
[..]
Again, *no* NAT'ing of IPv6.
How are you going to use ULA-C addresses as a source and then
connect to
hosts on the global Internet?
Not what I am proposing, and not desirable. ULA-C addresses
as source may not be compatible with global IPv6 addresses
as destination. Isn't that what source address selection
is for? I will say again that I do not support IPv6 NAT.
[..]
A laptop fits this description. Think of one running some
of this new virtualization support whereby there may be
many virtual machines connected up by virtual networks
running within the laptop. (Actually, folks like IBM were
doing this new virtualization on their mainframes back
in the 70's...)
I have one of those sweet laptops and I have 3 OS's running
at the same
time most of the time. I use RFC1918 and simply randomly picked
172.17.123.0/24 which has (upto now :) never collided with
the networks
that I visited. ULA (RFC4193) would have that same property. I have to
note that I have to NAT that address space to the network I am at, who
only give me 1 single IP address most of the time (could use bridging
and prolly ask for more addresses per DHCP of course). Having
them route
my prefix to me though everytime I walk into a Starbucks or a
hotel etc
is really never ever going to happen. There is no this is my prefix
route my traffic here protocol (at least yet). Also no single network
operator will ever accept such a protocol as it is their network, not
that of the visitor to control. Viruses and {cr|h}ackers
would love it I
guess.
Having my laptop inject its ULA(-C) prefix into a visited
network's IGP seems like one alternative, and I have not
investigated the various interactions you are describing.
But, injecting the prefix may not be the only alternative
and maybe not even be the best one.
When you are in the position to negotiate the routing part,
then having
them turn up DNS, which has to happen for both forward (how else are
they going to locate your host) and reverse hosts is very doable.
This then nullifies the whole requirement of having NS
pointers to your
servers, which have to have internet-connected and static addresses
unless you want to update them all the time, which for sure makes the
RIR happy who definitely want to have more cash then for doing that.
This is one part that I didn't understand very well.
Or are your requiring sites you visit to have Internet connectivity as
you only have your servers (forward + reverse) on the Internet?
Nor this.
this can
mean indeed a major corporation (who maybe even require
multiple /48's
which is why rfc4193 is a bit off to cover those cases)
If you want to have a /48 for your laptop, simply use ULA (RFC4193)
those are free.
RFC4193 ULA is good, but could be better. However remote the
possibility of collisions, IMHO there would still be value in
having a 3rd-party mechanism to avoid duplicate assignments
and/or de-conflict duplicates.
It exists: PI space. Get it at ARIN today: $100/year
Which if you have such a high reliability requirement for
non-clashes is
very cheap and gives you the possibility to do reverse DNS and even
route it on the global internet, just in case they provide you with
transit at the site you happen to come along.
I don't know enough about ARIN/PI to know who can get it, how
much it costs, how filters could be configured to recognize it,
etc. to be able to comment. Pretty much everything I know about
it I am learning through your posts, but my off-the-cuff take
is seems too expensive for small sites.
Or are you simply wanting to have your own IP
addresses,
setting up firewalling etc because you have a laptop (or Winnebago
filled with servers) and carrying it around globally
through various
buildings and making other networks accept your /48 AND
force them to
connect to the
Re: draft-ietf-ipv6-ula-central-02.txt
Templin, Fred L wrote: Jeroen, =20 Touching on just one aspect of your thoughtul post: =20 DNS is an integral part of addressing and if we're going to move forward with ULA-C as delegated=20 addressing then let us move forward with addressing in its entirety. So you want a disconnected address space which gets connected to the Internet? Sorry, but that more or less really implies NAT. =20 I wouldn't call it a disconnected address space which gets connected to the Internet but rather a unique local address space which gets connected to other unique local address spaces and IMHO I don't see any implication for NAT there. If you are only connecting to another ULA network, then why would one ever need NS entries in ip6.arpa for this space? Because sites will have *both* ULA-C and ordinary addresses. These sites may have private interconnects either due to bussiness needs or mergers or ... Because globally connected sites will see these addresses in logs, received headers etc. Queries for these addresses will be made from sites without reachabilty to these addresses. Then there is what do we do with all the reverse queries coming from sites that have failed to intercept the reverse queries. The whole story is about having NS entries in the ip6.arpa tree for the delegation. When you have a delegation in the Internet ip6.arpa tree, you also need to query them one way or the other and thus you are connecting your ULA-based network to that Internet. Not necessarially. Full disconnected sites will just maintain their own C.F.IP6.ARPA registry. Also, people will the notice that they can use reverses from the Internet, at one point or another will also want to use SIP or various other protocols and thus end up using the Internet, and there are two ways to do that: NAT it or simply announce the ULA prefix, renumbering to a PI block is of course not an option here. Why are you assuming a IPv4 solution to a IPv6 problem. If you have global reachability you will have global addresses. The anwer to how to talk to the Internet is to use a address with global scope. As such, what is the 'local' part again, how local is it really? And how is ULA-C then different from PI? Why bother people with this ULA-C thing when they really need PI in the first place? Which they can already get for $100/year from ARIN and which will be guaranteed unique, just like all other address space from the RIR's. Greets, Jeroen --enigA4239CC2518F4B232378ACE5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZ/3q4uFIAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I+i9AJwLWj1LkB4GArEMWLj9WI+6jf8V rgCgpOKskF+TzmhR+6NMycHte3Cq6os= =V6C5 -END PGP SIGNATURE- --enigA4239CC2518F4B232378ACE5-- --===0375020143== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --===0375020143==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
james woodyatt wrote: On Jun 25, 2007, at 09:33, Templin, Fred L wrote: I already gave my use-case in: http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html The use-case I am most interested in is Mobile Ad-Hoc Networks (MANETs) in which two or more MANETs can merge (e.g., due to mobility). If each MANET used ULA-C's, then they could inject each others' prefixes into their IGPs with no opportunity for collision. If each MANET instead used RFC4193 ULAs, then they could *probably* still inject each others' prefixes. But, however small the risk of collision, RFC4193 ULAs still have one drawback that ULA-C's do not - uncertainty. So perhaps another question is whether it is too much to ask for more certainty (ULA-C) and less mystery (RFC4193 ULA)? The no opportunity for collision thing is really the question here, as Brian E. Carpenter said in http://www1.ietf.org/mail-archive/web/ipv6/current/msg07834.html and others have said elsewhere. Most of the pushback is directed at this claim that central registration has some hope for mitigating an already *epsilon* risk of collision. I don't think simply reiterating the claim is an appropriate response to the legitimate rebuttal it's received. Depends on what level of collision risk you are happy with, and this depends on the scenario where you are assessing that risk. - you pick a number from a pool, I pick a number from a pool, then we compare numbers - chance of collision = 1 / pool size - a set of us pick numbers from a pool, and we compare numbers. The probability that two or us have picked the same number is the case where a random draw function exceeds 0.5 after 1.24 million random draws. The general solution of the probability of a collision after d draws from n possible values is given by: P = 1 - ((n!) / ((n**d)((n-d)!))) Given that the value for n here is 2.199,023,255,552, then the objective is to find the lowest value of d for which P is greater than or equal to 0.5. In this case the value for d is some 1.24 million. i.e. if we all pick numbers and stuff them into the DNS, then by the time the 1,240,000 selection had taken place the probability that a collision has occurred exceeds 0.5 regards, Geoff IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Depends on what level of collision risk you are happy with, and this depends on the scenario where you are assessing that risk. [...] - a set of us pick numbers from a pool, and we compare numbers. The probability that two or us have picked the same number is the case where a random draw function exceeds 0.5 after 1.24 million random draws. The general solution of the probability of a collision after d draws from n possible values is given by: P = 1 - ((n!) / ((n**d)((n-d)!))) Given that the value for n here is 2.199,023,255,552, then the objective is to find the lowest value of d for which P is greater than or equal to 0.5. In this case the value for d is some 1.24 million. i.e. if we all pick numbers and stuff them into the DNS, then by the time the 1,240,000 selection had taken place the probability that a collision has occurred exceeds 0.5 It's not a collision until two of those systems connect together. -- George Mitchell regards, Geoff IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
On Jun 25, 2007, at 17:01, Geoff Huston wrote: i.e. if we all pick numbers and stuff them into the DNS, then by the time the 1,240,000 selection had taken place the probability that a collision has occurred exceeds 0.5 That's only a problem for people who have to pick a number that collides with absolutely none of the other 1,240,000 numbers. I think no one will ever have to do that, and *moreover* I think that anybody who *does* think they'll have to do that has some explaining to do before we worry about their problem. Who's going to do that, and why? By the way, that is *NOT* a rhetorical question. I really want to know the answer. -- james woodyatt [EMAIL PROTECTED] member of technical staff, communications engineering IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
- a set of us pick numbers from a pool, and we compare numbers. The probability that two or us have picked the same number is the case where a random draw function exceeds 0.5 after 1.24 million random draws. The general solution of the probability of a collision after d draws from n possible values is given by: P = 1 - ((n!) / ((n**d)((n-d)!))) Given that the value for n here is 2.199,023,255,552, then the objective is to find the lowest value of d for which P is greater than or equal to 0.5. In this case the value for d is some 1.24 million. and this is based on a true random selection, yes? and we KNOW that humans are good at selecting truely random numbers. e.g. whats your favorite number between 1 and 2,199,023,255,552? ... that would be 42. i.e. if we all pick numbers and stuff them into the DNS, then by the time the 1,240,000 selection had taken place the probability that a collision has occurred exceeds 0.5 to Geo... the collision occurs at the point of intersection, be it when these sites interconnect or when they share a common namespace. regards, Geoff --bill IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08
At Mon, 25 Jun 2007 16:16:29 -0400, Hemant Singh (shemant) [EMAIL PROTECTED] wrote: First, it is not clear which security problem this bullet tries to indicate. hs The problem we refer to is the fact that Host1 and Host2 have the same GUA on the same link! This is an obvious problem because Host1 is able to get an authoritative (because Host1 issued an unchallenged DAD for GUA) GUA that is also later assigned to Host2. Note that Host1 does not need an incorrectly implemented or hacked up IPv6 stack to reach this problem scenario - the problem arises with a fully compliant IPv6 host stack on Host1 and Host2 using only the interface exported to an end user. If Host2 was NOT allowed to skip DAD, then Host2 will issue a NS(DAD) for GUA and Host1 being a compliant host would reply with an NA saying I have this GUA. The net result is that traffic that should have gone to Host2, goes to Host1 instead - why is this not a security problem? I, for one, would not call it a security problem; it's an accident. As an accident, the problem described in your draft is just another form of a weird situation that 2462bis already explains. And since the possibility of the accident didn't fully convince the opponents when we discussed 2462bis, I don't think this new draft can now do it. hs Do you acknowledge the problem we describe above? As an accident, yes. And I'm now more confident that it's not significant enough to delay the publication of 2462bis. Without the editor hat on: Since we realize that 2462bis I-D is in AUTH48 state, a change like this may require IETF-wide review and that would further delay 2462bis becoming an RFC. But then where do we put changes like ours? Our I-D is at the beginning of the process, so it may be an appropriate place for this and any further changes if they can't make it into 2462bis. Before seeking the place to put the changes, the draft first needs to convince others about the changes. If it goes successfully, the new document will be published as a separate RFC (I understand it's a time consuming process, but in my understanding standardization at the IETF works that way). JINMEI, Tatuya Communication Platform Lab. Corporate RD Center, Toshiba Corp. [EMAIL PROTECTED] IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt use cases
Apparently people are still having a hard time visualizing use cases for ULA-C, so let me try again to lay one out: Let's say I build a somewhat ad-hoc wireless mesh network covering a residential area to provide Internet service. For my Internet connectivity, I get service from several different ISPs, each of which gives me an IPv6 subnet (PA space). As this is a wireless network based on inexpensive hardware often deployed in a residential setting (and possibly involves some mobility), I can't count on any portion of my network to maintain reachability to any particular ISP uplink. In addition, I am likely to change ISPs over time, and I'm too small to qualify for PI space, so I choose to number my internal network infrastructure out of private (ULA) space. In parallel, I also use DHCP, DHCP-PD, etc. to assign subnets of my various PA space to users on various portions of my network (thereby giving them IPv6 address(es) of whichever Internet uplinks are available to them). (I may also use some form of DHCP to assign PA space to my router interfaces, or I may choose to hide that detail by doing my mesh networking below layer 3, or I may choose to use ULA space there and rewrite the source address of any ULA-sourced packets leaving my network for the Internet.) Now let's say I am thinking a little bit bigger than just my neighborhood, and would also like my network to connect to neighboring mesh networks. (This could fairly easily evolve into an arbitrarily large internetwork enabling disaster-resistant connectivity across neighborhoods, cities, or entire regions.) In order to facilitate troubleshooting, I elect to use ULA-C space for my network infrastructure, including router interfaces, (and either rewrite source addresses of any packets (presumably ICMP) my routers send out to the Internet, or also assign PA space to each interface with something like DHCP-PD, so that the router can use IPv6 address selection to use a public address for packets destined for public Internet addresses). As before, I would give out PA subnet(s) to users for Internet connectivity, but I might also elect to give them ULA addresses to communicate with other hosts on my mesh network and neighboring ones. In a situation like this, I need to be able to resolve PTRs for hosts using my neighboring networks' ULA space without any prior knowledge about the neighboring wireless network. If both networks are numbered out of ULA-C space, this is easy: I send my PTR queries to my regular DNS resolver, which has a PA address and Internet connectivity, and can resolve the PTR from the DNS server authoritative for my neighboring wireless network's ULA-C block. So, again, I see that ULA-C is a very simple solution to fill a very useful function that cannot be filled by local ULAs alone (at least without adding additional complexity to DNS). Importantly, this functionality does not depend on ULA-C providing an additional assurance of uniqueness, but on the fact that my block (and its authoritative DNS servers) can be registered, and others can query the registered data. As IPv6 adoption takes hold and dynamic wireless networking becomes cheaper and more widespread, I would see this kind of use case, and its many permutations, becoming more and more common. Can you describe a way to use existing address types available to small networks (PA and ULA-L) and existing DNS technologies to support the requirements listed above? If not, I would argue that we should complete the process of ULA-C standardization, as it represents the simplest available solution to the problem. -Scott IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
james woodyatt wrote: On Jun 25, 2007, at 17:01, Geoff Huston wrote: i.e. if we all pick numbers and stuff them into the DNS, then by the time the 1,240,000 selection had taken place the probability that a collision has occurred exceeds 0.5 That's only a problem for people who have to pick a number that collides with absolutely none of the other 1,240,000 numbers. I think no one will ever have to do that, and *moreover* I think that anybody who *does* think they'll have to do that has some explaining to do before we worry about their problem. Who's going to do that, and why? By the way, that is *NOT* a rhetorical question. I really want to know the answer. What I said above was and stuff them into the DNS i.e. when you have an environment that uniqueness is indeed critical and the number cannot collide with any other. i.e. IF you use the DNS for these numbers THEN this is a relevant issue. clear yet? And before you leap into I'm never going to use the DNS, so whats the problem? please also note that I'm not saying that putting these addresses into the DNS is good, bad or indifferent. What I was attempting to point out is that the factors that contribute to the risk of a collision depend on the nature of the environment where the numbers are used. One can hide in a small closet, lock the door, and in this little dark world of just you in your locked closet '1' is an entirely reasonable choice for a unique number. In other environments its probably a pretty poor choice! IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt use cases
Apparently people are still having a hard time visualizing use cases for ULA-C, so let me try again to lay one out: ... thanks. So, again, I see that ULA-C is a very simple solution to fill a very useful function that cannot be filled by local ULAs alone (at least without adding additional complexity to DNS). Importantly, this functionality does not depend on ULA-C providing an additional assurance of uniqueness, but on the fact that my block (and its authoritative DNS servers) can be registered, and others can query the registered data. if you want registration, then you want a new kind of RIR PI space, since it has to be unique, and the registration data has to be made and kept accurate. ... Now let's say I am thinking a little bit bigger than just my neighborhood, and would also like my network to connect to neighboring mesh networks. i like this vision, it matches my own. (This could fairly easily evolve into an arbitrarily large internetwork enabling disaster-resistant connectivity across neighborhoods, cities, or entire regions.) yes. In order to facilitate troubleshooting, I elect to use ULA-C space for my network infrastructure, including router interfaces, (and either rewrite source addresses of any packets (presumably ICMP) my routers send out to the Internet, or also assign PA space to each interface with something like DHCP-PD, so that the router can use IPv6 address selection to use a public address for packets destined for public Internet addresses). i was almost going to snort beer out my nose at how funny that was, until the millisecond when i realized that you didn't know it was funny to say in order to facilitate troubleshooting and then follow with that description of rube goldbergesque complexity. why did you leave out the part where the anvil that had been launched a few moments earlier finally, inevitably, lands on the coyote's midriff? but we (both) digress from the real point: In a situation like this, I need to be able to resolve PTRs for hosts using my neighboring networks' ULA space without any prior knowledge about the neighboring wireless network. which wouldn't be nec'y if both of these networks were in some new kind of PI space that was allocated out of a prefix designated by IANA for non-DFZ use. (i keep bringing the discussion back to that point because asking IANA to designate such a prefix ought to be the IETF's reaction to the ULA-C draft.) but i still digress, let's get to the meat of it: If both networks are numbered out of ULA-C space, this is easy: I send my PTR queries to my regular DNS resolver, which has a PA address and Internet connectivity, and can resolve the PTR from the DNS server authoritative for my neighboring wireless network's ULA-C block. here you're equating, dangerously in my opinion, three unrelated concepts: 1. public internet 2. PA address 3. internet connectivity please re-think this in terms of connectivity realms, of which the DFZ is one, and the american automotive exchange is another, and every fortune-2000 internal network is another, and every ad-hoc wireless mesh is another. in these terms, you'd have successfully pointed out that a given host may be in more than one connectivity realm, and that it's impossible to know in advance whether a network peer you reach in realm A can reach the same realm B that you can reach. now take it one step further -- stop according the DFZ any special status, treat it as just another connectivity realm to which any given network peer of yours may or may not have access. As IPv6 adoption takes hold and dynamic wireless networking becomes cheaper and more widespread, I would see this kind of use case, and its many permutations, becoming more and more common. me too. Can you describe a way to use existing address types available to small networks (PA and ULA-L) and existing DNS technologies to support the requirements listed above? If not, I would argue that we should complete the process of ULA-C standardization, as it represents the simplest available solution to the problem. i see ULA-C as a giant rubber band and some rocket powered roller skates which will finally, really, we mean it this time, allow the coyote to catch that darn roadrunner. the simpler solution is to recognize the following primary facts of reality: 1. every host needs a lan-scoped address 2. most hosts also need one or more global-scoped addresses 3. each of those global-scoped addresses will be in some connectivity realm 4. many of those connectivity realms will transitively, invisibly, overlap 5. the DFZ or public internet isn't special, it's just a connectivity realm 6. of all connectivity realms, the DFZ may not always be the largest one 7. all global-scoped addresses need ongoing reliable DNS and WHOIS support 8. address DNS/WHOIS support is traditionally a regional, bottom-up function if we can get agreement on those, then the resulting
RE: draft-ietf-ipv6-ula-central-02.txt
And before you leap into I'm never going to use the DNS, so whats the problem? please also note that I'm not saying that putting these addresses into the DNS is good, bad or indifferent. What about indifferent? Suppose that we pre-populate the ip6.arpa tree with synthetic name server records, so that the name server for a given ULA prefix ula-48::/48 (ULA-C or not) always resolves to ula-48::1 (or any other suitably chosen anycast host identifier). Then DNS look-up will always point to the closest instantiation of that anycast address, or to nothing at all if the prefix is not reachable. Voila, DNS look-up without any central registration... -- Christian Huitema IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
