Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum
On 20 aug 2008, at 21:33, Crist Clark wrote: No, that's my point. On a true point-to-point link, there is only one other address on the link. That's what point-to-point means. For example, on the IPv4 ends gif(4) tunnel in my previous message, gif0: flags=8051 metric 0 mtu 1280 tunnel inet 24.6.175.101 --> 72.52.104.74 inet6 fe80::200:24ff:feca:91b4%gif0 prefixlen 64 scopeid 0x7 inet6 2001:470:1f04:2fc::2 --> 2001:470:1f04:2fc::1 prefixlen 128 Note that this interface doesn't _have_ any IPv4 addresses: the IPv4 addresses that you see are the tunnel endpoints. However, the IPv6 addresses do what you say: there is a local one and a remote one and they don't share a subnet. Obviously it's possible to do this, but in my opinion, this is just an implementation variation, not the natural state of point-to-point links. It makes much more sense to have one set of behaviors that applies to all interfaces. And what is a point-to-point link, anyway? In theory gigabit ethernet is CSMA/CD, but I don't think anyone ever bothered to implement that, in practice it's point-to-point on layer 1, but layer 2 is point-to- multipoint...
Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum
Randy Bush wrote: and consider matsuzaki-san's dos vulnerability on a /64 p2p link. the prudent operational advice today is to use a /127. randy Can you provide some more information on this vulnerability? My google-fu appears to be weak. Sam
RE: It's Ars Tech's turn to bang the IPv4 exhaustion drum
A very old one:) http://atm.tut.fi/list-archive/ipng/msg00163.html Miya > -Original Message- > From: Sam Stickland [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 21, 2008 10:32 PM > To: Randy Bush > Cc: nanog list > Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum > > Randy Bush wrote: > > and consider matsuzaki-san's dos vulnerability on a /64 p2p > link. the > > prudent operational advice today is to use a /127. > > > > randy > > > > > Can you provide some more information on this vulnerability? > My google-fu appears to be weak. > > Sam > > >
Re: Is it time to abandon bogon prefix filters?
On Aug 20, 2008, at 7:00 AM, Kevin Loch wrote: It doesn't look like the feasible paths rpf handles the situation where your bgp customer is not announcing all or any of their prefixes to you. This can be done for TE or debugging an inbound routing issue. Announcing prefixes to me and then blackholing the traffic is not something I would appreciate as a customer. If you do this (or strict rpf) on BGP customers at least warn them up front that if they ever stop announcing prefixes to you then traffic they send you will get dropped. Clueful BGP admins know how to send their routes with no-advertise on them. There are fairly good reasons to require your direct customers always advertise their routes to you, even if you won't be readvertising them. uRPF is one. Not paying transit both inbound and out for multi- gig DoS attacks is my favorite. Etc. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Anyone from VisionNet AS8057 on list?
I'd like to talk to someone about a problem with some prefixes no longer working through your network. Please contact off list (email best) ThanksChuck Charles L. Mills Senior Network Engineer Access Data Corporation / Pittsburgh, PA 15238 Cmills at accessdc dot com This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this e-mail message in error, please notify the sender immediately by telephone or e-mail and destroy the original message without making a copy. Thank you. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.
Re: Is it time to abandon bogon prefix filters?
On Tue, 19 Aug 2008, Kevin Loch wrote: While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change. Isn't it time to change the assumption that sending arbitrary source IP addresses without checking is Ok? Unless the customer has specifically told their ISP about all the IP addresses they intend to use as source IP addresses, shouldn't the default be to drop those packets. If those multi-homed customers have not told their upstream ISPs about additional source IP addresses (hopefully also registered/authorized for use by the same customer) why can they still send packets with those source addresses? Instead shouldn't you say "Be careful if you are a using source IP addresses without informing your upstream." In practice, how many multi-homed customers send packets with unannounced source IP addresses? And for those customers which do, why is the ISP unable to implement any of the alternative source IP checking options, such as using a ACL with uRPF or on the interface?
Re: Is it time to abandon bogon prefix filters?
On Mon, 18 Aug 2008, Danny McPherson wrote: All the interesting attacks today that employ spoofing (and the majority of the less-interesting ones that employ spoofing) are usually relying on existence of the source as part of the attack vector (e.g., DNS cache poisoning, BGP TCP RST attacks, DNS reflective amplification attacks, etc..), and as a result, loose mode gives folks a false sense of protection/action. Yep. Same thing with bogon filters. Any attacker which can source packets with bogon addresses, can by definition, source packets with any "valid" IP address too. Great as an academic exercise, but the bad guys are going to send evil packets without the evil bit nor using bogon addresses. If the bad guys are using spoofed addresses, they don't care about the reply packets to either valid or unallocated addresses. However, seeing packets with unallocated IP addresses on the Internet is evidence of a broken network. Just like when a network trips "max prefix" on a BGP session, shouldn't a broken network be shutdown until the problem is fixed. If you don't want to risk your network peers turning off the connections, make sure your network doesn't source spoofed packets.
