RE: Important IPv6 Policy Issue -- Your Input Requested
"Depending on putting devices on 1918 for security is dangerous. " - Simon J. Lyall. Agreed. RFC 1918 is a good idea, it's not the law, and with that ISP's are not required to do anything about 1918 addr's if they choose not to. We receive a disturbingly large amount of traffic sourced from the 1918 space destined for our network coming from one of our normally respectable Tier 1 ISP's (three letter acronym, starts with 'M', ends with 'CI'). This is particularly irritating since we pay for burstable service; nice that we are paying for illegitimate traffic to come down our pipes. Their answer to this issue was: our routers can't handle the additional load that filtering 1918 traffic would cause. That's odd, I didn't think routing to Null0 (or equivalent) was all that taxing, I don't want an ACL, I want it gone in the cheapest, fastest way possible. With that it our (the global collective, not just my company) responsibility to prevent RFC 1918 traffic from entering our exiting our border; makes for an interesting definition of "private address space."
On 2004-11-09-17:10:02, "Network.Security" <Network.Security@target.com> wrote:
We receive a disturbingly large amount of traffic sourced from the 1918 space destined for our network coming from one of our normally respectable Tier 1 ISP's (three letter acronym, starts with 'M', ends with 'CI').
This is particularly irritating since we pay for burstable service; nice that we are paying for illegitimate traffic to come down our pipes. Their answer to this issue was: our routers can't handle the additional load that filtering 1918 traffic would cause.
That's odd, I didn't think routing to Null0 (or equivalent) was all that taxing, I don't want an ACL, I want it gone [...]
Null routes aren't going to stop packets with 1918 *sources* from entering your network, I'm afraid. This is where ACLs come into play. And it's quite conceivable, on a network of MCI's size, there are still peering and edge ports terminated by GSRs with engine 0 cards, or 7500s, or other hardware where bogon filtering and/or reverse-path validation really is a Big Deal(tm). -a (computing VJ's cell phone bill on the WRT54G as we speak)
----- Original Message ----- From: "Network.Security" <Network.Security@target.com>
On 2004-11-09-17:10:02, "Network.Security" <Network.Security@target.com> wrote:
We receive a disturbingly large amount of traffic sourced from the 1918 space destined for our network coming from one of our normally respectable Tier 1 ISP's (three letter acronym, starts with 'M', ends with 'CI').
This is particularly irritating since we pay for burstable service; nice that we are paying for illegitimate traffic to come down our pipes.
Hello. I felt I had to write a small comment to this. For the record, we use 1918 address range on several of our public routers meaning you will get legitimate traffic from this address space, atleast from us unless you are filtering it (which is of course all your decision). Filtering any type of traffic at all by a transit provider without the possibility to remove these filters _could_ be reason enough for us to terminate the contract with them since we would feel we were not paying for real internet connectivity. Joergen Hovland ENK
For the record, we use 1918 address range on several of our public routers meaning you will get legitimate traffic from this address space, atleast from us unless you are filtering it (which is of course all your decision). Filtering any type of traffic at all by a transit provider without the possibility to remove these filters _could_ be reason enough for us to terminate the contract with them since we would feel we were not paying for real internet connectivity.
perhaps you would benefit reading rfc 1918, and the prohibition of propagating 1918 space to the global net, before redifining 'real internet connectivity.' most of us would consider it a privilege not to have you as a customer. randy
----- Original Message ----- From: "Jørgen Hovland" <jorgen@hovland.cx> To: "Network.Security" <Network.Security@target.com> Cc: <nanog@merit.edu> Sent: Tuesday, November 09, 2004 7:06 PM Subject: Re: Important IPv6 Policy Issue -- Your Input Requested
----- Original Message ----- From: "Network.Security" <Network.Security@target.com>
On 2004-11-09-17:10:02, "Network.Security" <Network.Security@target.com> wrote:
We receive a disturbingly large amount of traffic sourced from the 1918 space destined for our network coming from one of our normally respectable Tier 1 ISP's (three letter acronym, starts with 'M', ends with 'CI').
This is particularly irritating since we pay for burstable service;
nice
that we are paying for illegitimate traffic to come down our pipes.
Hello. I felt I had to write a small comment to this.
For the record, we use 1918 address range on several of our public routers meaning you will get legitimate traffic from this address space, atleast from us unless you are filtering it (which is of course all your decision). Filtering any type of traffic at all by a transit provider without the possibility to remove these filters _could_ be reason enough for us to terminate the contract with them since we would feel we were not paying for real internet connectivity.
funny. you must be talking about a different internet. i hear there have been 'rumours out on the internets [sic]', maybe i'm just behind the times.. <g> all jokes aside, 1918 allows for use of 1918 space in a private network or a 'private internet [sic]' comprised of any such number of private networks as agree to interconnect and cooperate in routing traffic sourced from and destined to said space. it follows that any 1918-sourced traffic you send me is illegitimate. out of curiosity, what kind of 'legitimate traffic', considering i couldn't legitimately reply back, were you speaking of? p
paul@rusko.us ("Paul G") writes:
all jokes aside, 1918 allows for use of 1918 space in a private network or a 'private internet [sic]' comprised of any such number of private networks as agree to interconnect and cooperate in routing traffic sourced from and destined to said space. it follows that any 1918-sourced traffic you send me is illegitimate. ...
right, like this junk: 01:02:51.077156 10.14.0.16.32769 > 192.5.5.241.53: 64295 A? mx3.mail.yahoo.com. (36) (DF) 01:02:51.113972 10.38.0.15.53 > 192.5.5.241.53: 10929 [1au] PTR? 7.11.100.61.in-addr.arpa. (53) (DF) 01:02:51.113987 10.38.0.15.53 > 192.5.5.241.53: 65249 [1au] PTR? 18.73.178.24.in-addr.arpa. (54) (DF) 01:02:51.114845 10.38.0.15.53 > 192.5.5.241.53: 26736 [1au] PTR? 18.73.178.24.in-addr.arpa. (54) (DF) 01:02:51.116202 10.38.0.15.53 > 192.5.5.241.53: 44320 [1au] MX? labotte.ro. (39) (DF) 01:02:51.119806 10.38.0.15.53 > 192.5.5.241.53: 52979 [1au] PTR? 36.80.204.208.in-addr.arpa. (55) (DF) 01:02:51.120161 10.38.0.15.53 > 192.5.5.241.53: 39247 [1au][|domain] (DF) 01:02:51.121368 10.38.0.15.53 > 192.5.5.241.53: 48243 [1au] A? mx.114.com.cn. (42) (DF) 01:02:51.122435 10.38.0.15.53 > 192.5.5.241.53: 24334 [1au] MX? imarketpr.com. (42) (DF) 01:02:51.122511 10.38.0.15.53 > 192.5.5.241.53: 17621 [1au] A? c90619ac.virtua.com.br. (51) (DF) seems like rfc1918's prohibitions are not effective (and are unenforceable). i hope that there will be no more ops-relevant specs with harmful potential side-effects and ineffective+unenforceable prohibitions against those. and of course, see BCP38 (or if you're in management, SAC004). -- Paul Vixie
----- Original Message ----- From: "Paul Vixie" <vixie@vix.com> To: <nanog@merit.edu> Sent: Tuesday, November 09, 2004 8:04 PM Subject: Re: Important IPv6 Policy Issue -- Your Input Requested
paul@rusko.us ("Paul G") writes:
all jokes aside, 1918 allows for use of 1918 space in a private network or a 'private internet [sic]' comprised of any such number of private networks as agree to interconnect and cooperate in routing traffic sourced from and destined to said space. it follows that any
1918-sourced
traffic you send me is illegitimate. ...
right, like this junk:
seems like rfc1918's prohibitions are not effective (and are unenforceable). i hope that there will be no more ops-relevant specs with harmful
--- snip --- potential
side-effects and ineffective+unenforceable prohibitions against those.
i tend to view it as a subclass of spoofing, more specifically spoofing through stupidity/misconfiguration. the only difference i see between someone fat-fingering an ip address and this is, as is to be (sadly) expected, that some folk abuse 1918 as a basis to argue correctness in such cases. while i'm sure we can all agree that we would have liked to have less implied trust engineered into designs when those rfcs were penned, this is probably one of the least damaging cases and i tend to think that enforcement of 1918 belongs elsewhere, ie ipv# and bcp38.
and of course, see BCP38 (or if you're in management, SAC004).
given the track record of bcp38 and fiery debate resulting from the mention thereof on nanog-l, i propose to tack it onto the local list of corollaries of godwin's law <g> p
This thread was started by Leo Bicknell on Mon Nov 08 14:28:16 2004. The original post stated: "The IETF IPv6 working group is considering two proposals right now for IPv6 "private networks". Think RFC-1918 type space, but redefined for the IPv6 world. Those two drafts can be found at: "http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-07.tx t http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-00.txt" <snip> "Since this is a list of providers, I encourage you to read the drafts, and submit your comments to the working group. The information for the working group is at http://www.ietf.org/html.charters/ipv6-charter.html, and includes their mailing list archives and information on how to subscribe and/or post." "Even if you disagree with me, much like voting the important thing is that you voice your opinion." As Leo said, these two drafts are under consideration by the IP Version 6 Working Group (ipv6). Mail list information is: General Discussion: ipv6@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ipv6 In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/ipv6/index.html Looking at the archives for the working group there has been no recent discussion of these drafts. In the past two days there have been over 80 posts to this thread. This is a valuable discussion but to a large extent the efforts can be considered as a non input into the working group as the discussion is not on their mail list. The IETF works best when people directly contribute to the discussion and consensus building process. I encourage you to move this discussion to the working group mail list and if you are at the IETF to attend the IPv6 Working Group at 9 AM, Thursday morning in the Georgetown room. The session is also multicast. Ray
Ray Plzak wrote:
... This is a valuable discussion but to a large extent the efforts can be considered as a non input into the working group as the discussion is not on their mail list. The IETF works best when people directly contribute to the discussion and consensus building process. I encourage you to move this discussion to the working group mail list and if you are at the IETF to attend the IPv6 Working Group at 9 AM, Thursday morning in the Georgetown room. The session is also multicast.
I second Ray's comments about participation here. At the same time as you read and form your opinions, make sure you take off your blinders about how things were done in the good old days. Many current network deployments are work-arounds to the limitations of existing technology. There are opportunities for different configurations going forward that achieve the real goals. To that end, you should also read and comment on: draft-vandevelde-v6ops-nap-00.txt Another point to consider is that most of the people that would be using the ULA space are NOT service providers. As such you should keep in mind that the target user's problem is not the same as most of the membership of this list, so the tools and their use are not the same. While everyone could request space from a provider or Arin for private use, having a clean single well-known bogon filter of FC00/7 makes everyone's life much simpler. Since most of the problems in the operational world are derived from unnecessary complexity, having a simple well understood filter should lead us to a more stable network. Yes we know people leak 1918 today and ULAs don't prevent leaks, but leaks of space that was not intended to be globally routed will be even more common if they are non-contiguous random pieces from each customer. Tony
----- Original Message ----- From: "Paul G" <paul@rusko.us>
all jokes aside, 1918 allows for use of 1918 space in a private network or a 'private internet [sic]' comprised of any such number of private networks as agree to interconnect and cooperate in routing traffic sourced from and destined to said space. it follows that any 1918-sourced traffic you send me is illegitimate. out of curiosity, what kind of 'legitimate traffic', considering i couldn't legitimately reply back, were you speaking of?
I see I almost started an argument here. This was not my intention. Data from unconnected sockets only: Udp and icmp messages (unreachable etc). Joergen Hovland ENK
----- Original Message ----- From: "Jørgen Hovland" <jorgen@hovland.cx> To: <nanog@merit.edu> Sent: Tuesday, November 09, 2004 8:07 PM Subject: Re: Important IPv6 Policy Issue -- Your Input Requested
----- Original Message ----- From: "Paul G" <paul@rusko.us>
all jokes aside, 1918 allows for use of 1918 space in a private network
or
a 'private internet [sic]' comprised of any such number of private networks as agree to interconnect and cooperate in routing traffic sourced from and destined to said space. it follows that any 1918-sourced traffic you send me is illegitimate. out of curiosity, what kind of 'legitimate traffic', considering i couldn't legitimately reply back, were you speaking of?
I see I almost started an argument here. This was not my intention. Data from unconnected sockets only: Udp and icmp messages (unreachable etc).
that's great. on behalf of everyone who's ever had the joy of troubleshooting connectivity issues, i thank you, kind sir. jokes aside again, why would you even bother sending back diagnostic data when you've essentially halved the usefulness of it? p
----- Original Message ----- From: "Paul G" <paul@rusko.us>
I see I almost started an argument here. This was not my intention. Data from unconnected sockets only: Udp and icmp messages (unreachable etc).
that's great. on behalf of everyone who's ever had the joy of troubleshooting connectivity issues, i thank you, kind sir.
jokes aside again, why would you even bother sending back diagnostic data when you've essentially halved the usefulness of it?
Hi again, We simply did not want the routers to be globally available nor revealing the ownership due to security reasons, but still permit that other half to receive diagnostic data. If you must get into further details please let us discuss it off the list. Joergen Hovland ENK
On Tue, 9 Nov 2004, Network.Security wrote:
"Depending on putting devices on 1918 for security is dangerous. " - Simon J. Lyall.
Agreed. RFC 1918 is a good idea, it's not the law, and with that ISP's are not required to do anything about 1918 addr's if they choose not to. We receive a disturbingly large amount of traffic sourced from the 1918 ^^^^^^^
That's odd, I didn't think routing to Null0 (or equivalent) was all that taxing, I don't want an ACL, I want it gone in the cheapest, fastest way possible.
that's odd... routing is a DESTINATION based problem, not a SOURCE based one.
Christopher L. Morrow wrote:
On Tue, 9 Nov 2004, Network.Security wrote:
"Depending on putting devices on 1918 for security is dangerous. " - Simon J. Lyall.
Agreed. RFC 1918 is a good idea, it's not the law, and with that ISP's are not required to do anything about 1918 addr's if they choose not to. We receive a disturbingly large amount of traffic sourced from the 1918
^^^^^^^
That's odd, I didn't think routing to Null0 (or equivalent) was all that taxing, I don't want an ACL, I want it gone in the cheapest, fastest way possible.
that's odd... routing is a DESTINATION based problem, not a SOURCE based one.
Routing has always been more than a destination based decision. Even in the beggining IP had LSRR/SSRR. Now it has policy/qos/SAV/urpf what have you. <Tinfoil Hat> The redefinition of ip routing as actions based solely on the destination address in the packet was done merely by those wishing to ignore performance requirements for doing it properly. They took the cheap easy way out. Kudos to all you grizzled folk out there who handed out those free passes. (After 20 years of IP we now offer line rate X as long as you dont do Y!) </TH> (back to my corner for the rest of the month)
On Wed, 10 Nov 2004, Joe Maimon wrote:
Christopher L. Morrow wrote:
That's odd, I didn't think routing to Null0 (or equivalent) was all that taxing, I don't want an ACL, I want it gone in the cheapest, fastest way possible.
that's odd... routing is a DESTINATION based problem, not a SOURCE based one.
Routing has always been more than a destination based decision. Even in the beggining IP had LSRR/SSRR.
Sure, ip-options bits were/are allowed for LSRR/SSRR, which as you said below is disabled for a multitude of reasons on many/most/all (?) large parts of the Internet for many reasons, not the least of which is performance penalties. So, aside from the 2 examples routing ip has been a hop-by-hop destination based problem, source addresses (even with LSRR/SSRR I believe) has little to do with the equation. I could be wrong, I am just a chemical engineer. If this was a distillation column or a raction vessel I might be more sure :
I could be wrong, I am just a chemical engineer. If this was a distillation column or a raction vessel I might be more sure :
actually, i think you happen to be one of the maybe 25% of participants in this discussion that is an actual operator on a real network. rarer and rarer. :-( and if nanog ain't a reaction vessel, what is? and i suspect a number of participants are too near distillations when they type. :-) randy
On Wed, 10 Nov 2004, Randy Bush wrote:
I could be wrong, I am just a chemical engineer. If this was a distillation column or a raction vessel I might be more sure :
actually, i think you happen to be one of the maybe 25% of participants in this discussion that is an actual operator on a real network. rarer and rarer. :-(
I see its time to quit then! :)
and if nanog ain't a reaction vessel, what is? and i suspect a number of participants are too near distillations when they type. :-)
Seriously though, Leo's note and concerns about private-use ipv6 are real issue. I think I'll read (two more days of ipv6 hell it seems) the ietf lists and send some comments their way. As an operator (security wonk really despite my love of the distillation and reaction equipments) there are 'good' and 'bad' in the private addressing schemes. Good: "allows people to keep their privates private" (basically) "permits people to have test and devel systems without wasting public space" Bad: "more hell of 1918" "clashes where we wouldn't expect, when we can't afford, with folks we didn't know" "less 'waste' for private peoples" (others in both categories of course) good thing ipv6 is infinite and non-exhasutable! :)
participants (10)
-
Adam Rothschild -
Christopher L. Morrow -
Joe Maimon -
Jørgen Hovland -
Network.Security -
Paul G -
Paul Vixie -
Randy Bush -
Ray Plzak -
Tony Hain