RE: Purpose of spoofed packets ???
One more outré purpose for spoofing SIPs is to have you blacklist/nullroute someone, effectively enlisting you to cause a DOS. --p -Original Message- From: NANOG [mailto:nanog-bounces+patrick.darden=p66@nanog.org] On Behalf Of Matthew Huff Sent: Tuesday, March 10, 2015 6:41 PM To: nanog@nanog.org Subject: [EXTERNAL]Purpose of spoofed packets ??? We recently got an abuse report of an IP address in our net range. However, that IP address isn't in use in our networks and the covering network is null routed, so no return traffic is possible. We have external BGP monitoring, so unless something very tricky is going on, we don't have part of our prefix hijacked. I assume the source address was spoofed, but this leads to my question. Since the person that submitted the report didn't mention a high packet rate (it was on ssh port 22), it doesn't look like some sort of SYN attack, but any OS fingerprinting or doorknob twisting wouldn't be useful from the attacker if the traffic doesn't return to them, so what gives? BTW, we are in the ARIN region, the report came out of the RIPE region. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669
Re: distinguishing eBGP from show ip BGP
Thanks again, Mark. So I guess the short answer is that I can't infer anything about the location of physical connectivity having this level of information from the control plane. Is that a fair statement? What if the Next Hop is inside the neighbor AS. I know it is a rather odd and uncommon case, but can it help? Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Wed, Mar 11, 2015 at 3:50 PM, Mark Tinka mark.ti...@seacom.mu wrote: On 11/Mar/15 21:42, Reza Motamedi wrote: What I ultimately want to determine, is the location of the AS connection. I know for example the router is in, say LA. If hot potato lets me to send the packet to the neighbor AS then they have an AS connection in LA, right? Going back to my example does the fact that the entry does not have 'i' mean that I can send it to AS2828 on the next hop. Yes - the route was not learned via iBGP; which means it was learned via eBGP. But that is just routing. It does not necessarily paint the forwarding topology (remember, routing and forwarding are two different operations). The next-hop may be local to this router, but it could also be a tunnel (which may be cold-potato forwarded before exiting the local AS), or the eBGP session could be eBGP Multi-Hop. Mark.
Re: NDS Resolution Problems between Charter Communications and OpenDNS
Yea, sorry. DNS -- I was hammering that out before running out the door. DNS is the issue -- as far as I know, it's still an issue. From: NANOG nanog-boun...@nanog.org on behalf of Chuck Church chuckchu...@gmail.com Sent: Monday, March 9, 2015 12:36 PM To: nanog@nanog.org Subject: RE: NDS Resolution Problems between Charter Communications and OpenDNS NDS? My first suggestion would be run DSREPAIR. Wow, that brings back memories. But since you probably mean DNS, I'll stop right there. Chuck -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Christopher Dye Sent: Monday, March 09, 2015 1:20 PM To: nanog@nanog.org Subject: NDS Resolution Problems between Charter Communications and OpenDNS If anyone from Charter Communications NetOps or OpenDNS NetOps is monitoring, could you please contact me off-list? It would seem AS36692 (OpenDNS) and AS23028 (Charter Communications) are having some issues playing together. Thanks Much, Chris Dye Chief Technical Officer Paragon Solutions Group, Inc.
Re: distinguishing eBGP from show ip BGP
On 11/Mar/15 22:27, Reza Motamedi wrote: Thanks again, Mark. So I guess the short answer is that I can't infer anything about the location of physical connectivity having this level of information from the control plane. Not reliably as far as I can tell, no. Someone else can chime in here if they have another perspective. One could rely on traceroutes, but that is crude and sometimes unavailable if you're looking to gather any meaningful data (even though it might be the closest piece of information you'll get without engaging with the network operator). What if the Next Hop is inside the neighbor AS. I know it is a rather odd and uncommon case, but can it help? Control-plane-wise, that could be eBGP Multi-Hop. Forwarding-plane-wise, that is likely a tunnel operation. Technically, one can build such a topology. I'd hazard that at least someone is doing this out there somewhere. However, it's not typical by any means. Mark.
Re: distinguishing eBGP from show ip BGP
On Wed, Mar 11, 2015 at 02:32:33PM -0400, Reza Motamedi wrote: Hi Nanog, For a research I want to distinguish the external AS peering from show ip BGP. In other words I want to see which entry show a path that immediately sends packets to another AS. My understanding is that *status code* shows if the route is internal, right? Does this mean if the *'i' *is not present, the route is goes out of the AS in the next hop. On the same note, can I use Next Hop to identify such entries? I would take a different route to diagnose the relationship between networks. I would look at the route-views or RIS datasets and parse the MRT data taking a close look at the communties that are tagged on the routes. NTT (2914) tags routes based on if they are a customer, peer and with geographic communities based on where the route enters our network. Many networks perform similar techniques and you can find details at various websites or this one: http://www.onesc.net/communities/ You will likely get far more accurate data. You can also attempt to validate these relationships leveraging the RIPE ATLAS project. You can then perform tests and validate them via traceroutes performed by this global network of probes. You can also look at the NLNOG-RING project as another location to perform these tests from. aside: if you want RIPE Atlas credits, let me know, my cup overflows with credits. I just included a sample report from a public looking glass in XO. show ip bgp 207.108.0.0/15 longer-prefixes BGP table version is 529230540, local router ID is 65.106.7.145 * * *Status codes: s suppressed, d damped, h history, * valid, best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * 207.108.0.0/15 216.156.2.1643 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i * 216.156.2.1622 0 2828 209 i * 65.106.7.54 3 0 2828 209 i * 65.106.7.252 2 0 2828 209 i * 216.156.2.1602 0 2828 209 i * 65.106.7.56 3 0 2828 209 i * 216.156.2.1652 0 2828 209 i * 65.106.7.144 2 0 2828 209 i these next-hops can tell you information about the internal of a network, how they are configured, eg: with route-reflectors, next-hop-self or other policies internally. The i at the end is an origin code, which is used as a tie-breaker for the BGP decision process. This can be influenced by people to set it to internal, external or unknown to cause shifts in traffic. internal tagged routes will have a higher preference when reaching a network, so there are some networks that may reset the origin to influence the policy of a 3rd party network. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: distinguishing eBGP from show ip BGP
What I ultimately want to determine, is the location of the AS connection. I know for example the router is in, say LA. If hot potato lets me to send the packet to the neighbor AS then they have an AS connection in LA, right? Going back to my example does the fact that the entry does not have 'i' mean that I can send it to AS2828 on the next hop. Network Next HopMetric LocPrf Weight Path * 207.108.0.0/15 216.156.2.1643 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i * 216.156.2.1622 0 2828 209 i Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Wed, Mar 11, 2015 at 3:30 PM, Mark Tinka mark.ti...@seacom.mu wrote: On 11/Mar/15 21:22, Reza Motamedi wrote: Thanks Mark for the reply. Let me try to check what I understood is correct. Does the 'i' on the left (status code) only shows whether the prefix belongs to this AS? Status-code i just means the entry was learned by this router via iBGP. It does not mean the entry belongs to this AS. A locally-generated route can be thought of as belonging to this AS, however, a router cannot assert that a locally-generated route belongs to this AS. It just asserts that the route was locally-generated within the AS. Ownership of the route is data that needs to be gleaned from other sources, e.g., RIR WHOIS data, speaking to the operator, e.t.c. Whatever the case, a locally-generated route would not have an AS_PATH. That is an easy way to tell for such a use-case. What I want to figure out is if this two ASes (the owner of the router and and the first one on the AS-PATH) connect at the location of the router, or if packets need to stay for some hops in the local AS. So you want to determine whether traffic is hot- or cold-potato forwarding from the point of view of your reference router? Mark.
Re: distinguishing eBGP from show ip BGP
Thanks Mark for the reply. Let me try to check what I understood is correct. Does the 'i' on the left (status code) only shows whether the prefix belongs to this AS? What I want to figure out is if this two ASes (the owner of the router and and the first one on the AS-PATH) connect at the location of the router, or if packets need to stay for some hops in the local AS. On Wed, Mar 11, 2015, 2:51 PM Mark Tinka mark.ti...@seacom.mu wrote: On 11/Mar/15 20:32, Reza Motamedi wrote: Hi Nanog, For a research I want to distinguish the external AS peering from show ip BGP. In other words I want to see which entry show a path that immediately sends packets to another AS. My understanding is that *status code* shows if the route is internal, right? Does this mean if the *'i' *is not present, the route is goes out of the AS in the next hop. On the same note, can I use Next Hop to identify such entries? I just included a sample report from a public looking glass in XO. show ip bgp 207.108.0.0/15 longer-prefixes BGP table version is 529230540, local router ID is 65.106.7.145 * * *Status codes: s suppressed, d damped, h history, * valid, best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * 207.108.0.0/15 216.156.2.1643 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i * 216.156.2.1622 0 2828 209 i * 65.106.7.54 3 0 2828 209 i * 65.106.7.252 2 0 2828 209 i * 216.156.2.1602 0 2828 209 i * 65.106.7.56 3 0 2828 209 i * 216.156.2.1652 0 2828 209 i * 65.106.7.144 2 0 2828 209 i There are two uses of the i code in IOS: 1. i for Status codes refers to the route being learned via iBGP. 2. i for Origin codes refers to the route being learned via a locally-generated route at the origin (or more historically, the IGP). In IOS show ip bgp output, the i for Status code (iBGP) is to the left of the prefix. On the other hand, the i for Origin code (IGP-originated route) is to the right of the originating AS in the AS_PATH. So you need to be more interested in the i to the left of the prefix. In your output above, no such i exists; ergo, these are eBGP-learned routes from this router's point of view. Use of the NEXT_HOP attribute to identify whether a route is eBGP-learned is not reliable, especially if you do not own the network you're getting your data from. Mark.
Re: distinguishing eBGP from show ip BGP
On 11/Mar/15 21:22, Reza Motamedi wrote: Thanks Mark for the reply. Let me try to check what I understood is correct. Does the 'i' on the left (status code) only shows whether the prefix belongs to this AS? Status-code i just means the entry was learned by this router via iBGP. It does not mean the entry belongs to this AS. A locally-generated route can be thought of as belonging to this AS, however, a router cannot assert that a locally-generated route belongs to this AS. It just asserts that the route was locally-generated within the AS. Ownership of the route is data that needs to be gleaned from other sources, e.g., RIR WHOIS data, speaking to the operator, e.t.c. Whatever the case, a locally-generated route would not have an AS_PATH. That is an easy way to tell for such a use-case. What I want to figure out is if this two ASes (the owner of the router and and the first one on the AS-PATH) connect at the location of the router, or if packets need to stay for some hops in the local AS. So you want to determine whether traffic is hot- or cold-potato forwarding from the point of view of your reference router? Mark.
Re: distinguishing eBGP from show ip BGP
On 11/Mar/15 20:32, Reza Motamedi wrote: Hi Nanog, For a research I want to distinguish the external AS peering from show ip BGP. In other words I want to see which entry show a path that immediately sends packets to another AS. My understanding is that *status code* shows if the route is internal, right? Does this mean if the *'i' *is not present, the route is goes out of the AS in the next hop. On the same note, can I use Next Hop to identify such entries? I just included a sample report from a public looking glass in XO. show ip bgp 207.108.0.0/15 longer-prefixes BGP table version is 529230540, local router ID is 65.106.7.145 * * *Status codes: s suppressed, d damped, h history, * valid, best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * 207.108.0.0/15 216.156.2.1643 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i * 216.156.2.1622 0 2828 209 i * 65.106.7.54 3 0 2828 209 i * 65.106.7.252 2 0 2828 209 i * 216.156.2.1602 0 2828 209 i * 65.106.7.56 3 0 2828 209 i * 216.156.2.1652 0 2828 209 i * 65.106.7.144 2 0 2828 209 i There are two uses of the i code in IOS: 1. i for Status codes refers to the route being learned via iBGP. 2. i for Origin codes refers to the route being learned via a locally-generated route at the origin (or more historically, the IGP). In IOS show ip bgp output, the i for Status code (iBGP) is to the left of the prefix. On the other hand, the i for Origin code (IGP-originated route) is to the right of the originating AS in the AS_PATH. So you need to be more interested in the i to the left of the prefix. In your output above, no such i exists; ergo, these are eBGP-learned routes from this router's point of view. Use of the NEXT_HOP attribute to identify whether a route is eBGP-learned is not reliable, especially if you do not own the network you're getting your data from. Mark.
Re: distinguishing eBGP from show ip BGP
On 11/Mar/15 20:51, Jared Mauch wrote: NTT (2914) tags routes based on if they are a customer, peer and with geographic communities based on where the route enters our network. Many networks perform similar techniques and you can find details at various websites or this one: http://www.onesc.net/communities/ You will likely get far more accurate data. The trick with relying on BGP communities to map routing data is that their propagation between AS's is not always guaranteed. Mark.
distinguishing eBGP from show ip BGP
Hi Nanog, For a research I want to distinguish the external AS peering from show ip BGP. In other words I want to see which entry show a path that immediately sends packets to another AS. My understanding is that *status code* shows if the route is internal, right? Does this mean if the *'i' *is not present, the route is goes out of the AS in the next hop. On the same note, can I use Next Hop to identify such entries? I just included a sample report from a public looking glass in XO. show ip bgp 207.108.0.0/15 longer-prefixes BGP table version is 529230540, local router ID is 65.106.7.145 * * *Status codes: s suppressed, d damped, h history, * valid, best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * 207.108.0.0/15 216.156.2.1643 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i * 216.156.2.1622 0 2828 209 i * 65.106.7.54 3 0 2828 209 i * 65.106.7.252 2 0 2828 209 i * 216.156.2.1602 0 2828 209 i * 65.106.7.56 3 0 2828 209 i * 216.156.2.1652 0 2828 209 i * 65.106.7.144 2 0 2828 209 i Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon
Re: distinguishing eBGP from show ip BGP
On Mar 11, 2015, at 2:59 PM, Mark Tinka mark.ti...@seacom.mu wrote: On 11/Mar/15 20:51, Jared Mauch wrote: NTT (2914) tags routes based on if they are a customer, peer and with geographic communities based on where the route enters our network. Many networks perform similar techniques and you can find details at various websites or this one: http://www.onesc.net/communities/ You will likely get far more accurate data. The trick with relying on BGP communities to map routing data is that their propagation between AS's is not always guaranteed. True, they also can get marked, remarked, or dropped at various network edges. This is why I was suggesting taking the data directly from the MRT files at route-views. I’ve been using this for the routing leak detector just processing the updates over the years and it’s way easier to process a smaller update file than diff the entire RIB dump. (at least for that use-case). rant=start Many people who do BGP don’t do a good job with their policy which is how you end up with these full table leaks and seemingly random routes appear that hairpin through networks. eg: 59.188.253.0/24 2497 701 6453 45474 174 17444 It’s unlikely that 6453 or 701 should really be using 45474 to reach 174 or their customer 17444. This has a lot to do with IOS devices which by default send all routes to all configured peers. Cisco does a particularly poor job of educating it’s CCIE and other graduates of this fact. IOS-XR can be made to do the same thing, but requires explicitly enabling this problematic behavior. Similarly send-community on IOS requires beyond the basic “neighbor 1.2.3.4 remote-as 5” type config. rant=end - Jared
Re: distinguishing eBGP from show ip BGP
On 11/Mar/15 21:42, Reza Motamedi wrote: What I ultimately want to determine, is the location of the AS connection. I know for example the router is in, say LA. If hot potato lets me to send the packet to the neighbor AS then they have an AS connection in LA, right? Going back to my example does the fact that the entry does not have 'i' mean that I can send it to AS2828 on the next hop. Yes - the route was not learned via iBGP; which means it was learned via eBGP. But that is just routing. It does not necessarily paint the forwarding topology (remember, routing and forwarding are two different operations). The next-hop may be local to this router, but it could also be a tunnel (which may be cold-potato forwarded before exiting the local AS), or the eBGP session could be eBGP Multi-Hop. Mark.
Re: Phone adapter with router
On 11 March 2015 at 11:04, Aled Morris al...@qix.co.uk wrote: Can't find a definitive reference but this concurs with my recollection of a policy introduced in 2009: Better reference: http://ec.europa.eu/information_society/newsroom/cf/document.cfm?doc_id=1674 1.3. Availability of 112 from mobile handsets without SIM cards By way of complementary information, the countries were invited to indicate whether SIM-less 112 calls were allowed. Out of the 31 countries that provided this information, SIM-less 112 calls were reported possible in 19 Member States, Norway and Iceland. The remaining eight Member States that do not provide this facility are Bulgaria, Germany (in both these countries the facility was removed in 2009), the Netherlands (removing the facility in 2011) Belgium, France, Romania, Slovenia, and the United Kingdom. Several Member States chose to remove this facility because of the high proportion of hoax calls originating from SIM less phones. Aled
Re: Phone adapter with router
On 11/03/2015 10:02, Baldur Norddahl wrote: It should be possible to do the emergency call without a SIM. That way you got 112 / 911 calls covered... emergency calls without sim are part of the gsm standard. So unless the OP's provider is doing something terribly wrong and probably illegal, you can make a 112 call on any mobile device anywhere in the world within range of a compatible radio signal. Nick
Re: Phone adapter with router
On 11 March 2015 at 10:45, Nick Hilliard n...@foobar.org wrote: On 11/03/2015 10:02, Baldur Norddahl wrote: It should be possible to do the emergency call without a SIM. That way you got 112 / 911 calls covered... emergency calls without sim are part of the gsm standard. So unless the OP's provider is doing something terribly wrong and probably illegal, you can make a 112 call on any mobile device anywhere in the world within range of a compatible radio signal. Can't find a definitive reference but this concurs with my recollection of a policy introduced in 2009: http://www.redcross.org.uk/en/What-we-do/Teaching-resources/Quick-activities/999 Some people think that 999 calls can be made from a phone without a SIM. In fact, because of the high number of hoax calls, the United Kingdom decided to block emergency calls from mobile phones without a SIM card. Aled
Re: NDS Resolution Problems between Charter Communications and OpenDNS
Hi Christopher, feel free to contact me with more details via andree at opendns com Cheers Andree .-- My secret spy satellite informs me that at 2015-03-11 2:56 PM Christopher Dye wrote: Yea, sorry. DNS -- I was hammering that out before running out the door. DNS is the issue -- as far as I know, it's still an issue. From: NANOG nanog-boun...@nanog.org on behalf of Chuck Church chuckchu...@gmail.com Sent: Monday, March 9, 2015 12:36 PM To: nanog@nanog.org Subject: RE: NDS Resolution Problems between Charter Communications and OpenDNS NDS? My first suggestion would be run DSREPAIR. Wow, that brings back memories. But since you probably mean DNS, I'll stop right there. Chuck -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Christopher Dye Sent: Monday, March 09, 2015 1:20 PM To: nanog@nanog.org Subject: NDS Resolution Problems between Charter Communications and OpenDNS If anyone from Charter Communications NetOps or OpenDNS NetOps is monitoring, could you please contact me off-list? It would seem AS36692 (OpenDNS) and AS23028 (Charter Communications) are having some issues playing together. Thanks Much, Chris Dye Chief Technical Officer Paragon Solutions Group, Inc.
