Recently in кровавая гэбня Category

Сегодня все блоги шумят на предмет того, что Yota заблокировала доступ к целому набору сайтов оппозиции: http://www.kasparov.ru, http://www.nazbol.ru, http://www.rusolidarnost.ru, http://www.rufront.ru, http://www.newtimes.ru, http://www.kavkazcenter.com.

Где-то я это уже слышал :)

Ну естественно, я не мог пройти мимо. Я побежал в ближайшую точку продаж и купил модем. Благо, Yota проводит акцию try and buy. Так что у меня есть целая неделя, чтобы покопаться.

Итак, втыкаем модем, проделываем все положенные прыжки и ужимки на предмет регистрации, и идем на http://www.kasparov.ru и видим: "Firefox не может установить соединение с сервером www.kasparov.ru.".

Круто! Проблема действительно воспроизводится, а значит ее можно исследовать. Проверяем выборочно сайты из списка, и таки да.

Первым делом - проверяем, туда ли мы идем, и не пытаются ли нас обмануть на этапе DNS. Сразу замечаем, что kavkazcenter.com резолвится в 127.0.0.1. С этим сайтом все понятно - он в цензурном списке, и Yota его блокирует без всякого стеснения. Это нормально. "Нормально" не в том, смысле, что я это одобряю - нет, я категорически этого не одобряю и желаю всяческих несчастий всем любителям запретить книжку, газетку или сайтик, какая бы "дрянь" ни была в них написана. Но Йоту можно понять: суд постановил - будь добр выполнять. Увы :(

Остальные же резолвятся совершенно нормально, т.е. в те адреса, в которые должны. В чем же тогда дело?

Берем инструмент и начинаем внимательно разглядывать, что же происходит на самом деле.

03:08:27.979656 IP (tos 0x0, ttl 128, id 42765, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3055 > 67.218.116.57.80: S, cksum 0x34cb (correct), 3633491279:3633491279(0) win 64512 <mss 1360,nop,nop,sackOK>
03:08:30.954162 IP (tos 0x0, ttl 128, id 42768, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3055 > 67.218.116.57.80: S, cksum 0x34cb (correct), 3633491279:3633491279(0) win 64512 <mss 1360,nop,nop,sackOK>
03:08:33.920210 IP (tos 0x0, ttl 253, id 14323, offset 0, flags [none], proto TCP (6), length 40) 67.218.116.57.80 > 10.128.254.2.3055: R, cksum 0x6117 (correct), 0:0(0) ack 3633491280 win 64512
03:08:34.371135 IP (tos 0x0, ttl 128, id 42769, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3055 > 67.218.116.57.80: S, cksum 0x34cb (correct), 3633491279:3633491279(0) win 64512 <mss 1360,nop,nop,sackOK>
03:08:41.140576 IP (tos 0x0, ttl 253, id 13272, offset 0, flags [none], proto TCP (6), length 40) 67.218.116.57.80 > 10.128.254.2.3055: R, cksum 0x9b8c (correct), 2287877420:2287877420(0) ack 1 win 64512

Так. К нам прилетает RST от сайта. Это, в принципе возможно, но поглядим на TTL: он равен 253. Т.е. тот, кто сгенерировал этот пакет, находится от нас не далее, чем в двух хопах - в сети Йоты! Кто-то в промежутке активно вмешивается в нашу TCP-сессию. Пора подозревать неладное.

Когда есть подозрение на странное поведение промежуточного хопа, то лучше всего исследовать такие случаи путем одновременной записи пакетов с обеих сторон. Так и поступим: у меня есть домашняя машинка, подключенная к Акадо.

Со стороны ноутбука на Yota:
03:52:48.544886 IP (tos 0x0, ttl 128, id 45230, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3138 > 83.167.114.17.80: S, cksum 0xa2c8 (correct), 2900385036:2900385036(0) win 64512 <mss 1360,nop,nop,sackOK>
03:52:51.555732 IP (tos 0x0, ttl 128, id 45234, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3138 > 83.167.114.17.80: S, cksum 0xa2c8 (correct), 2900385036:2900385036(0) win 64512 <mss 1360,nop,nop,sackOK>
03:52:55.595682 IP (tos 0x0, ttl 253, id 24737, offset 0, flags [none], proto TCP (6), length 40) 83.167.114.17.80 > 10.128.254.2.3138: R, cksum 0xcf14 (correct), 0:0(0) ack 2900385037 win 64512
03:52:56.082060 IP (tos 0x0, ttl 128, id 45235, offset 0, flags [DF], proto TCP (6), length 48) 10.128.254.2.3138 > 83.167.114.17.80: S, cksum 0xa2c8 (correct), 2900385036:2900385036(0) win 64512 <mss 1360,nop,nop,sackOK>
03:53:03.016041 IP (tos 0x0, ttl 253, id 19571, offset 0, flags [none], proto TCP (6), length 40) 83.167.114.17.80 > 10.128.254.2.3138: R, cksum 0x1ede (correct), 509841875:509841875(0) ack 1 win 64512

Со стороны домашнего компа на Акадо:
03:52:49.348749 IP (tos 0x0, ttl 116, id 45230, offset 0, flags [DF], proto TCP (6), length 48) 109.188.11.104.3138 > 192.168.1.254.80: S, cksum 0xe72c (correct), 2068504495:2068504495(0) win 64512 <mss 1360,nop,nop,nop,nop>
03:52:52.323674 IP (tos 0x0, ttl 116, id 45234, offset 0, flags [DF], proto TCP (6), length 48) 109.188.11.104.3138 > 192.168.1.254.80: S, cksum 0xe72c (correct), 2068504495:2068504495(0) win 64512 <mss 1360,nop,nop,nop,nop>
03:52:56.271631 IP (tos 0x0, ttl 245, id 24736, offset 0, flags [none], proto TCP (6), length 40) 109.188.11.104.3138 > 192.168.1.254.80: R, cksum 0x0c89 (correct), 2068504496:2068504496(0) win 0
03:52:57.018421 IP (tos 0x0, ttl 116, id 45235, offset 0, flags [DF], proto TCP (6), length 48) 109.188.11.104.3138 > 192.168.1.254.80: S, cksum 0xe870 (correct), 2390543161:2390543161(0) win 64512 <mss 1360,nop,nop,nop,nop>
03:53:03.689851 IP (tos 0x0, ttl 245, id 19570, offset 0, flags [none], proto TCP (6), length 40) 109.188.11.104.3138 > 192.168.1.254.80: R, cksum 0x0dcd (correct), 2390543162:2390543162(0) win 0

Первое, что бросается в глаза, - мы получили в точности ту же картику, что и с kasparov.ru, если глядеть со стороны Йоты! Т.е. злые цензоры заблокировали и мою домашнюю машину, чтобы она не нарушала гармонию неуместной надписью "It works!" большими черными буквами на белом фоне.

Второе, и на сервер приходят RST якобы от моего ноутбука: SYN, а следом за ним RST от того же хоста, с тех же портов. Хотя со стороны ноутбука видно, что он получает RST, а никак не посылает. Поэтому приходится заключить, что RST возникают в сети Йоты самостоятельно и непрошенно.

Честное слово, оппозиционер из меня хреновый. Ну, разве что кухонный - так, побухтеть. И на машинке той ничего не живет - апач на ней только для всяких экспериментов, которые боязно проводить там, где этот блог находится. Поэтому мысль о том, что Йота каким-то специальным образом меня ненавидит, придется отмести, как неорганизованную :)

В чем же дело? А вот в чем. Мой домашний апач существует, как я уже сказал, только для экспериментов, и отвечает только весьма небольшому количеству внешних хостов. Убираем файрвольное правило, и, вуаля, все работает замечательно - никаких лишних RST. Нормальную сессию я выкладывать не буду - она скучная, поскольку нормальная.

Вот как интересно получается. Если моя машина работает нормально, то Йота в сессию не вмешивается. А ежели сервер на запросы молчит, то через 6-7 секунда Йота сессию обресечивает. Выходит, левые RST возникают, если на дальнем конце что-то не так.

Зачем Йота может это делать? Я подозреваю, что это попытка освобождать память на ихнем NAT'е побыстрее.

Где же тогда проблема? Берем tcptraceroute (вернее, его аналог по винду) и смотрим:
C:\Documents and Settings\dginsburg\My Documents\tmp\tcpt>tracetcp.exe www.kasparov.ru:80 -t 500

Tracing route to 67.218.116.57 on port 80
Over a maximum of 30 hops.
1       *       *       *       Request timed out.
2       *       *       *       Request timed out.
3       *       *       *       Request timed out.
4       *       *       *       Request timed out.
5       *       *       *       Request timed out.
6       199 ms  127 ms  102 ms  213.248.103.177 [mow-m9-i2-link.telia.net]
7       125 ms  125 ms  261 ms  80.91.253.230   [mow-b2-link.telia.net]
8       291 ms  115 ms  113 ms  80.91.249.210   [s-bb1-link.telia.net]
9       268 ms  217 ms  268 ms  213.248.65.25   [kbn-bb1-pos0-0-0.telia.net]
10      289 ms  215 ms  238 ms  80.91.249.21    [nyk-bb1-link.telia.net]
11      338 ms  312 ms  297 ms  80.91.252.153   [sjo-bb1-link.telia.net]
12      350 ms  305 ms  360 ms  80.239.193.126  [layer42-ic-120233-sjo-bb1.c.telia.net]
13      343 ms  476 ms  330 ms  69.36.225.135   [vl2.sw2.scl.layer42.net]
14      307 ms  420 ms  295 ms  67.218.116.57
15      *       *       *       Request timed out.
16      *       *       *       Request timed out.
17      *       *       *       Request timed out.
18      *
Terminate Event Occurred.

Во-первых, наши пакетики покидают сеть Йоты. Во-вторых, доходят до цели, но там куда-то деваются. В точности так же, как было в эксперименте с моей домашней машиной до убирания файрвольного правила.

Подобьем бабки:
1) kavkazcenter.com действительно заблокирован, и заблокирован явно
2) пакеты в сторону kasparov.ru идут и покидают Йоту совершенно успешно
3) очень похоже, что kasparov.ru не отвечает в сторону Йоты.

Если внимательно погуглить, то можно найти, что проблемы возникают только если йотиному юзеру не повезло, и он натится в сеть 109.188.0.0/18. Что может быть причиной?

Мое предположение состоит вот в чем: блок адресов 109/8 был отдан RIPE для раздачи только в начале этого года. До этого он лежал про запас, а следовательно, фигурировал в списках bogons. Некоторые излишне озабоченные безопасностью люди фильтруют маршруты, пакеты или и то, и то, по этим самым bogon lists, но всегда забывают их обновить. Пруфлинк: http://mailman.nanog.org/pipermail/nanog/2009-October/013941.html (обратите внимание на дату).

(Тяжело вздыхая) Что я могу сказать по всему этому поводу? Много чего. Преимущественно нецензурного.

Update: вот, собственно, и yota отписалась - http://community.livejournal.com/yota_ru/660659.html. Я оказался прав.

Just for a change I'm going to try to blog in [admittedly broken] English. Hey, Petr, I'm jealous about your postings in internetworkexpert.com blog and the feedback you're getting, and I'm going to catch up. Just kidding. ;)

Next, I'm going to use Junos examples to illustrate this posting instead of IOS. I've finally got my olives in qemu working nicely on my home PC, and I'm anxious to put it to use.

The problem

A couple of weeks ago my LJ-friend visir has asked an interesting question: "Assume we have a client, which also peers at the same IX as we do. Then the client can defraud us. They can announce /22 on their direct link to us and one or two /23 through the IX route server. Now traffic from the Internet to that prefix flows to us, and takes exit at the IX to the client. Our client enjoys a free ride stealing bandwidth from us. How do you deal with this problem?"

If you think about it, it may sound somewhat weird. We're basically peering with our own customer. Well, that can and does happen in the real world. So we have to come up with a solution.

In fact, this problem with peering isn't new. It was mentioned a few times on various mailing lists and there was a presentation at NANOG 38 in 2006, describing a whole set of possible tricks a peer can play on you. I suggest reading the presentation before continuing with this posting. Please note, that it is not limited to peering; even your upstream can do nasty things to you.

Speaking of possible solutions, I'd like to point out that having a written and signed agreement is an absolute must when dealing with service stealing issues. Yes, it applies to peering as well, not only to Internet transit. Do have a peering agreement, which clearly states what a peer can do. No agreement - no ground for complaints. It leads us to observation 0: being promiscuous in your relationships is asking for trouble (you probably knew that before). The observation basically rules out peering with route server on IXs in favor of direct peering. Sure, direct peering is not always possible, so weigh your risks carefully when engaging in an IX peering.

That was a short comment on administrative side of the issue. Now to the technical one.

Luckily, there're technical ways to mitigate the threat, so you don't have to rely on administrative measures only.

Technical solution boils down to enforcing certain routing policies. The rules are:
1. Traffic ingressing from an upstream must flow only to a customer.
2. Traffic ingressing from a peer must flow only to a customer.
3. Traffic ingressing from a customer must flow to a customer if a customer route exists, otherwise it can flow to upstream or peer.

How can we enforce the policy? Clearly, control-plane-only solution is not sufficient (you've read NANOG presentation above, haven't you?). We have to somehow couple forwarding plane operations to control plane policy.

Other solutions

There're quite a few known solutions to this issue.

One from Juniper-land: DSU/SCU and their usage in firewall policies. Basically DSU/SCU is a method of grouping traffic on destination or source address. We could group all traffic in three classes: customer, upstream and peer, and then employ class-based filtering to enforce our rules.

Another one is from Cisco-land: QPPB. There's a quite cool method described in details in another NANOG presentation: http://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf.

These solutions can deal with the problem, but there's a catch. They are designed to drop traffic when a peer tries to defraud us. This is a problem, because even unintentional misconfiguration (say, a sloppy attempt at traffic engineering) will result in service disruption. It would be nice, if we could handle it better and somehow ignore fraudulent/erroneous routes.

You've probably noticed in abovementioned presentations references to separate routers carrying partial routes. Yes, it can solve the problem, but it is uneconomical.

One can employ virtualization, i.e. logical routers, VRFs etc. But it is still uneconomical. You need a separate VRF per peer, if you don't want your peers to talk to each other through you. And a separate VRF per upstream, if you want enforce routing policy on traffic, coming from upstream providers too (remember, upstreams can also play games on you). Just imagine the amount of route replication between VRFs. It not only taxes on router memory and CPU resources, it also wastes precious FIB space - keeping several BGP full views each in separate VRF is very, very expensive.

Still, virtualization (or compartmentalization, if you will) is a very powerful method to deal with our problem. Let's try to design a practical method to use it.

The problem demonstrated

This is our playgroud where we're going to test our findings.



Nothing fancy in the setup. IS-IS, LDP, iBGP full mesh between border routers, and eBGP to external autonomous systems. eBGP export policies are configured as usual: customer prefixes are announced to upstream ISP, local prefixes are announced everywhere, upstream and peer prefixes are announced only to customers.

AS 4 is a customer, AS 3 is a peer (a well behaved one), AS 100 is an upstream ISP. AS 2 is a customer, which is trying to defraud us. AS 2 has customer link to router BORDER-3 and a peering link to BORDER-2. AS 2 announces 2.0.0.0/8 route over the customer link and 2.0.0.0/9 over the peering link.

Let's see the issue in action.

dg@UPSTREAM> show route 2.0.0.1 terse

inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 2.0.0.0/8          B 170        100            >100.0.1.1       1 2 I

dg@UPSTREAM> traceroute 2.0.0.1    
traceroute to 2.0.0.1 (2.0.0.1), 30 hops max, 40 byte packets
 1  100.0.1.1 (100.0.1.1)  0.761 ms  96.959 ms  100.964 ms
 2  1.0.255.0 (1.0.255.0)  158.851 ms  104.946 ms  106.054 ms
     MPLS Label=100016 CoS=0 TTL=1 S=1
 3  1.0.255.3 (1.0.255.3)  201.972 ms  104.960 ms  105.964 ms
 4  2.0.1.0 (2.0.1.0)  105.393 ms  52.344 ms  154.138 ms
 5  2.0.1.0 (2.0.1.0)  149.144 ms !H  105.044 ms !H  106.142 ms !H

You can see that traffic exits on the peering link to AS 2. Bad, bad, bad. Same with traffic from customer (AS 4), and even from a peer (AS 3).

Design and implementation

If you look at our rules again, you can see that a packet must be treated differently, depending on where it is coming from. That's observation 1.

We must make routing decisions (i.e. select egress point) right on ingress point, and once we've selected the egress point, we must not change it while the packet travels through our network. That's observation 2.

How do we implement this?

We want to make different routing decisions based on what the ingress link is: a customer, an upstream, or a peer. This implies multiple routing tables, right? But haven't we concluded that keeping separate routing tables for each upstream or peer is out of the question? Not exactly so. Keeping lots of copies of lots of routes is wrong; having multiple routing tables is ok, if we can populate them in an efficient way.

Let's see what additional routing/forwarding tables do we need and what routes they need to carry. Let's take a routing table to forward traffic coming from an upstream ISP. It needs to carry only customers' routes, locally originated routes, but not peer or upstream routes. Same with routing table for a peer. Do we need separate routing tables for each upstream or peer? No. If a routing table has only customer and local routes, then it is ok to use only one instance to forward traffic from all upstreams and peers connected to a router.

How can this be achieved? The idea is to have an external entity to run BGP signaling to our master routing instance (global routing table in Cisco speak), populate a restricted routing instance with needed routes from master routing instance, and then forward traffic from that entity within that restricted routing instance. We can do that with so called FBF (Filter Based Forwarding).

interfaces {
    fxp2 {          
        unit 0 {    
            family inet {
                filter {
                    input restricted;
                }   
            }       
        }
    }
}

routing-options {
    auto-export;
}

policy-options {
    policy-statement client-and-local-only {
        term local {
            from community local;
            then accept;
        }
        term client {
            from community client;
            then accept;
        }
        then reject;
    }
    policy-statement restricted-import {
        term needed-routes {
            from {  
                instance master;
                policy client-and-local-only;
            }       
            then accept;
        }           
        then reject;
    }               
}

firewall {
    filter restricted {
        term bgp-passive {
            from {
                destination-port bgp;
            }
            then accept;
        }
        term bgp-active {
            from {
                source-port bgp;
            }       
            then accept;
        }           
        term other {
            then routing-instance restricted;
        }           
    }               
}

routing-instances {
    restricted {    
        instance-type forwarding;
        routing-options {
            static {
                route 0.0.0.0/0 discard;
            }       
            instance-import restricted-import;
        }           
    }            
}

Traffic coming from a customer is slightly different. Remember rule 3: ... must flow to a customer if a customer route exists, otherwise it can flow to upstream or peer.

What we need to do in this case is to look up a customer route first, and if there's no such route, then we fallback to looking up a peer or an upstream route. So we make another routing instance, which again carries customer and local prefixes, and also add a fallback route to it. Again, a single such routing instance is sufficient to forward traffic from all customers.

Configuration is very similar to previuosly shown, but instead of default discard route we configure lookup in master routing table.

routing-instances {
    restricted-fallback {
        instance-type forwarding;
        routing-options {
            static {
                route 0.0.0.0/0 next-table inet.0;
            }       
            instance-import restricted-import;
        }           
    }               
}

It is pretty economical way to use multiple routing tables. We only have to replicate customer and local routes and we have to do that only to two extra tables, regardless of number of external commections on the router.

Let's now tackle with observation 2. Let me show why it is important. This is traceroute after we implemented restricted routing tables.

dg@UPSTREAM> traceroute 2.0.0.1 source 100.0.0.0    
traceroute to 2.0.0.1 (2.0.0.1) from 100.0.0.0, 30 hops max, 40 byte packets
 1  100.0.1.1 (100.0.1.1)  0.893 ms  99.335 ms  96.004 ms
 2  1.0.255.0 (1.0.255.0)  96.225 ms  240.356 ms  95.819 ms
     MPLS Label=100000 CoS=0 TTL=1 S=1
 3  1.0.255.5 (1.0.255.5)  95.861 ms  95.646 ms  96.030 ms
 4  1.0.255.4 (1.0.255.4)  192.635 ms  95.277 ms  144.631 ms
     MPLS Label=100016 CoS=0 TTL=1 S=1
 5  1.0.255.3 (1.0.255.3)  144.381 ms  148.101 ms  144.356 ms
 6  2.0.1.0 (2.0.1.0)  144.571 ms  100.139 ms  96.159 ms
 7  2.0.1.0 (2.0.1.0)  139.571 ms !H  196.818 ms !H  95.966 ms !H

See, a packet from upstream comes in to BORDER-1, BORDER-1 forwards it to BORDER-3 over LDP-signaled LSP, then BORDER-3 makes it's own routing decision and reroutes the packet to BORDER-2, and the packet exits to the peering link to AS2. We haven't achieved anything!

The problem is with penultimate hop popping. With PHP, a packet arrives at the egress router striped of MPLS headers, and the egress router makes routing decision based on destination IP address. This is not what we want. There're chances that the egress router will make a different routing decision and forward the packet to a different exit point. How can this be avoided? The answer is simple: use one more label. PHP will pop the top label, and the egress router will forward the packet based on the remaining label without looking at IP header. This can be easily achieved with labeled IPv4 unicast address family on our iBGP sessions.

protocols {
    bgp {               
        group ibgp {
            type internal;
            local-address 1.0.0.1;
            family inet {
                labeled-unicast;
            }
            neighbor 1.0.0.2;
            neighbor 1.0.0.3;
        }
    }
}

There's small catch though. We must enable family mpls on our external interfaces, otherwise this setup doesn't work (Is this olive's artifact? I don't have enough real equipment to verify it). This opens our network for label spoofing attack. Thus we must attach a filtering policy to family mpls on our external interfaces.

interfaces {
    fxp1 {          
        unit 0 {
            family mpls {
                filter {
                    input-list drop-mpls;
                }
            }
        }
    }
}

firewall {
    family mpls {
        filter drop-mpls {
            term all {
                then discard;
            }
        }
    }
}

Let's see how is all works together.

dg@UPSTREAM> traceroute 2.0.0.1
traceroute to 2.0.0.1 (2.0.0.1) from 100.0.0.0, 30 hops max, 40 byte packets
 1  100.0.1.1 (100.0.1.1)  1.103 ms  98.689 ms  100.819 ms
 2  1.0.255.0 (1.0.255.0)  100.305 ms  240.509 ms  100.759 ms
     MPLS Label=100000 CoS=0 TTL=1 S=0
     MPLS Label=100064 CoS=0 TTL=1 S=1
 3  1.0.255.5 (1.0.255.5)  51.932 ms  192.196 ms  105.548 ms
     MPLS Label=100064 CoS=0 TTL=1 S=1
 4  1.0.2.1 (1.0.2.1)  148.946 ms  100.330 ms  100.693 ms
 5  1.0.2.1 (1.0.2.1)  96.588 ms !H  153.207 ms !H  101.018 ms !H

dg@CUSTOMER> traceroute 2.0.0.1    
traceroute to 2.0.0.1 (2.0.0.1) from 4.0.0.0, 30 hops max, 40 byte packets
 1  1.0.4.0 (1.0.4.0)  0.744 ms  100.479 ms  102.213 ms
 2  1.0.255.0 (1.0.255.0)  102.067 ms  152.851 ms  101.834 ms
     MPLS Label=100000 CoS=0 TTL=1 S=0
     MPLS Label=100064 CoS=0 TTL=1 S=1
 3  1.0.255.5 (1.0.255.5)  101.457 ms  152.631 ms  153.512 ms
     MPLS Label=100064 CoS=0 TTL=1 S=1
 4  1.0.2.1 (1.0.2.1)  101.715 ms  50.052 ms  153.585 ms
 5  1.0.2.1 (1.0.2.1)  102.267 ms !H  100.998 ms !H  153.793 ms !H

dg@PEER> traceroute 2.0.0.1
traceroute to 2.0.0.1 (2.0.0.1) from 3.0.0.0, 30 hops max, 40 byte packets
 1  1.0.3.0 (1.0.3.0)  0.662 ms  90.742 ms  87.542 ms
 2  1.0.255.2 (1.0.255.2)  91.884 ms  215.552 ms  91.635 ms
     MPLS Label=100000 CoS=0 TTL=1 S=0
     MPLS Label=100064 CoS=0 TTL=1 S=1
 3  1.0.255.5 (1.0.255.5)  45.099 ms  157.433 ms  125.233 ms
     MPLS Label=100064 CoS=0 TTL=1 S=1
 4  1.0.2.1 (1.0.2.1)  132.577 ms  132.641 ms  91.394 ms
 5  1.0.2.1 (1.0.2.1)  103.895 ms !H  145.040 ms !H  133.256 ms !H

Now traffic coming in from customers, upstreams or peers takes the correct route. The fraudulent routes from AS2 are simply ignored.

Acknowledgements

Many thanks to Andrew Lomaka, who has pointed out this problem to me few years ago, shared lots of operational wisdom pertaining to the issue, answered many of my silly questions, and also helped to debug the configuration I described above.

На слешдоте обсуждали грузинскую цензуру по отношению к российским новостным сайтам. Утверждают, что блокировка - DNS-based. Похоже, что это и в самом деле так, но этим оно не ограничивается.

[13:42] dg@iddater:~$ dig @62.168.168.2 lenta.ru. any

; <<>> DiG 9.3.4 <<>> @62.168.168.2 lenta.ru. any
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49807
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;lenta.ru.                      IN      ANY

;; AUTHORITY SECTION:
ru.                     86400   IN      SOA     ns0.caucasus.net. root.caucasus.net. 2008102903 14400 3600 1209600 172800

;; Query time: 170 msec
;; SERVER: 62.168.168.2#53(62.168.168.2)
;; WHEN: Mon Aug 18 13:43:08 2008
;; MSG SIZE  rcvd: 83

Видно, что люди решили проблему радикально, и в соответствии с принципом “Разве может что-нибудь хорошее прийти из Назарета?”, накрыли медным тазом целый TLD.

Кстати, есть у кого-нибудь предположения, что может означать такой странный serial?

Для особо умных, которые умеют обращаться с собственным рекурсором и не пользуются провайдерским, есть второй слой блокировки - на уровне IP.

Вот пинги lenta.ru:

PING 81.19.69.232 (81.19.69.232) 56(84) bytes of data.
From 80.241.178.70 icmp_seq=3 Packet filtered

--- 81.19.69.232 ping statistics ---
3 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2009ms

Как видно, приезжает ICMP 3/13 от 80.241.178.70.

И соседнего адреса:
PING 81.19.69.233 (81.19.69.233) 56(84) bytes of data.
64 bytes from 81.19.69.233: icmp_seq=1 ttl=42 time=132 ms
64 bytes from 81.19.69.233: icmp_seq=2 ttl=42 time=131 ms
64 bytes from 81.19.69.233: icmp_seq=3 ttl=42 time=132 ms

--- 81.19.69.233 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2037ms
rtt min/avg/max/mdev = 131.702/132.192/132.802/0.544 ms

Как видно, тут сделано несколько поизбирательней - блокируется только "вражеская пропаганда".

От оценок я воздержусь, пусть каждый делает выводы сам.

Вечер пятницы - время для досужих мечтаний. Вот и мне после вкусного ужина со стаканчиком пива слегка подумалось.

Вот какая есть штука: между работой data plane и работой control/management plane сетевого элемента есть существенный концептуальный разрыв.

Если опустить некоторые детали и упростить, то control/management plane оперирует понятиями логического интерфейса, адреса, маршрута, т.д., а на data plane ничего подобного нет, там есть физическая веревка, несколько таблиц и несколько простых операций: lookup в той или иной таблице (с возможным ее пополнением) по одному или нескольким полям, переписывание части пакета, передача его в физическую веревку или опять на lookup в другой таблице. А все эти subinterfaces, pseudowires, vlans, vrfs и прочая, и прочая, в терминах которых мы конфигурим наши железки, - их на самом деле нет, это интерфейс к реальным механизмам форвардинга, абстракция, предоставленная нам производителем роутера.

Хорошо это или плохо? С одной стороны это хорошо, поскольку необходимо, т.к. те же протоколы маршрутизации оперируют теми же понятиями интерфейса, адреса, маршрута. С другой стороны, иногда эти выразительные средства не позволяют добиться желаемого поведения сетевого элемента, или позволяют ценой немыслимых извращений, или насколько криво отображаются в примитивные средства data plane, что это приводит к самым неочевидным эффектами, из которых потеря в производительность не самый страшный, хотя и самый распространенный. Leaky abstraction и abstraction inversion во всей своей красе.

До относительно недавних пор все двигалось в одну сторону - когда кастомеры били ногами вендора, вендор вводил фичу, расширяя и усложняя control plane'овую абстракцию, но все же оставаясь в ее рамках. Так и появлялись всякие "this over that support", "whatever scalability enhancements", "virtual something", которыми пестрят release notes каждой новой версии софта. Это оптимизации, это поддержанные на официальном уровне accidental features, это закрытие зияющих прорех абстракции. И все это ad hoc, все лоскутно, все реактивно, а не проактивно.

Однако, недавно циску (у некоторых других вендоров есть, кажется, похожие вещи) это достало, и она сделала EVC (Ethernet Virtual Circuit). Это конфигурационный механизм, который позволяет определять поведение непосредственно в терминах match-rewrite-forward. По .1q'шным тэгам, но это уже хорошо. Этот EVC - большой рулез. Это гибкий механизм, который позволяет делать более естественно, то что можно было делать раньше с помощью субинтерфейсов, и делать новые, ранее невозможные вещи. Правильная, очень правильная вещь.

Но этого мало. Я хочу распространения похожего механизма на все data plane'овые операции. Это очень облегчило бы жизнь. Сразу исчезли бы глупые и крайне неочевидные хаки типа global keyword для статических маршрутов в VRF, или совершенно ужасного GRT prefix import into a VRF. Можно было бы строить интересные и полезные наложенные топологии со смешанным L2/L3 форвардингом (ох, у фанатов модели OSI сейчас будет инфаркт, хехе).

Я прекрасно отдаю себе отчет, что возможности разных платформ очень разные, и такой механизм был бы очень тесно привязан к платформе. Ну и что. Можно сделать это платформозависимо, можно придумать что-то вроде MQC - на самом деле, если немного расширить PBR, скомбинировать его с EVC, то получится похоже на то, что я хочу.

В ru_telecom@lj сегодня часа в 2 ночи какое-то существо запостило следующий текст (пост удален, но яндекс все помнит):

17 мая 2008 года около 11:30 рейдерами был захвачен домен, с 1997 года принадлежащий ОАО "Вашъ Финансовый Попечитель" - VFP.RU. Подложный сайт компании разместился в хостинговом центре ХЦ РБК. 20 мая контроль над доменом был восстановлен. В базе данных компании-регистратора RU-CENTER появились новые, легитимные данные об адресе настоящего сайта ОАО "ВФП" - 195.68.187.163. Но не все серверы доменных имен обновили информацию о вэб-сайте. Например, серверы компании Голден Телеком (194.85.128.10 и 194.85.129.80) указывают на заведомо ложный адрес нашего сайта. Получается, что Рунет (по крайней мере его часть) не является свободной средой распространения информации, а используется некоторыми нечистоплотными операторами для выполнения рейдерских заказов.

Ахринеть. Круто. Смотрим.

$ whois vfp.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain:     VFP.RU
type:       CORPORATE
nserver:    ns.vfp.ru. 195.68.187.163
nserver:    ns.rusmedia.net.
state:      REGISTERED, DELEGATED
org:        Vash Finansovy Popechitel Ltd.
phone:      +7 495 2536984
fax-no:     +7 495 9564386
e-mail:     boris@vfp.ru
registrar:  RUCENTER-REG-RIPN
created:    1997.09.24
paid-till:  2008.10.01
source:     TC-RIPN


Last updated on 2008.05.23 10:41:53 MSK/MSD

На TLD-серверах все зашибись:

$ dig +nostats +nocomments vfp.ru @NS.RIPN.NET

; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @NS.RIPN.NET
; (1 server found)
;; global options:  printcmd
;vfp.ru.                                IN      A
vfp.ru.                 345600  IN      NS      ns.rusmedia.net.
vfp.ru.                 345600  IN      NS      ns.vfp.ru.
ns.vfp.ru.              345600  IN      A       195.68.187.163

Смотрим на авторитетные сервера для зоны:

$ dig +nostats +nocomments vfp.ru @195.68.187.163

; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @195.68.187.163
; (1 server found)
;; global options:  printcmd
;vfp.ru.                                IN      A
vfp.ru.                 7200    IN      A       195.68.187.163
vfp.ru.                 7200    IN      NS      ns.rusmedia.net.
vfp.ru.                 7200    IN      NS      ns.vfp.ru.
ns.vfp.ru.              7200    IN      A       195.68.187.163
$ dig +nostats +nocomments vfp.ru @195.68.187.163 soa

; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @195.68.187.163 soa
; (1 server found)
;; global options:  printcmd
;vfp.ru.                                IN      SOA
vfp.ru.                 7200    IN      SOA     ns.vfp.ru. root.ns.vfp.ru. 200701230 7200 600 3600000 7200
vfp.ru.                 7200    IN      NS      ns.rusmedia.net.
vfp.ru.                 7200    IN      NS      ns.vfp.ru.
ns.vfp.ru.              7200    IN      A       195.68.187.163
$ dig +nostats +nocomments vfp.ru @ns.rusmedia.net

; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @ns.rusmedia.net
; (1 server found)
;; global options:  printcmd
;vfp.ru.                                IN      A
vfp.ru.                 7200    IN      A       213.243.107.145
vfp.ru.                 7200    IN      NS      ns.rusmedia.net.
vfp.ru.                 7200    IN      NS      ns.vfp.ru.
ns.vfp.ru.              7200    IN      A       213.243.107.145
ns.rusmedia.net.        43200   IN      A       195.230.64.13
$ dig +nostats +nocomments vfp.ru @ns.rusmedia.net soa

; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @ns.rusmedia.net soa
; (1 server found)
;; global options:  printcmd
;vfp.ru.                                IN      SOA
vfp.ru.                 7200    IN      SOA     ns.vfp.ru. root.ns.vfp.ru. 200701230 7200 600 3600000 7200
vfp.ru.                 7200    IN      NS      ns.rusmedia.net.
vfp.ru.                 7200    IN      NS      ns.vfp.ru.
ns.vfp.ru.              7200    IN      A       213.243.107.145
ns.rusmedia.net.        43200   IN      A       195.230.64.13

Что видим? Видим стандартную ньюбисную ошибку - отредактировали зону, но забыли поменять сериал. Бывает. Но ведь нет, надо обязательно возопить, что теплая куча в штанах - это не мы обгадились, это проделки рейдеров (кровавой гэбни, жыдомарсиан, цру, бабы яги). Тьфу.

Пошел я сегодня на blog.yandex.ru поискать, что пишут про несогласных и их сайты, в надежде обнаружить какое-то развитие событий.

Все почему-то прицепились к ихнему DNS'у. Ну, резолвится kasparov.ru в один адрес, а www.kasparov.ru в другой. kasparov.ru всегда выдает редирект на www.kasparov.ru, а второй, собственно, раздает контент. Ну находятся эти машины на разных площадках, ну и что. Да, несколько необычная конструкция. Кривенькая. Чем руководствовались те, кто это сделал, сказать трудно. Возможно, действительно, это остаточные явления какого-то переезда. Но ничего неслыханного в такой конструкции нет. Это не причина недоступности сайтов. Я в своем прошлом посте на тему несогласных сайтов даже не упомянул про эту особенность, посчитав, что всем и так все понятно. Ан нет.

Я понимаю, написать в газетной статье, что "сайты www.kasparov.ru (69.36.240.70) и kasparov.ru (216.92.221.10) имеют разные адреса", существенно легче, чем вдаваться в нудные рассуждения про tcp window и syn cookie. Да и ожидать от журналиста понимания этих вещей невозможно. Но как-то мне неуютно от того, что широко распространяемые опровержения истерики госпожи Литвинович не намного технически грамотнее самой истерики

This entry was originally posted in my livejournal

Миф о Всесильном Тоталитарном Режиме, стремящимся удушить все Силы Добра, никак не дает покоя представителям этих самых сил. Не успела отгреметь истерика по поводу "цензуры" в ЖЖ, как тут же выпрыгнули очередные умучанные от гэбни.

Ко вчерашнему.

Некоторые могли обратить внимание, что если пойти на http://community.livejournal.com/ru_politics, будучи незалогиненым, то ЖЖ честно покажет "This journal has been suspended.". А если пойти залогиненым, то ВСЕ ОПЯТЬ ПОВИСНЕТ, АААА!!!! Псы Тоталитарного Режима отслеживают невинных пользователей, интересующихся крамольным коммьюнити, и берут на карандашик!!! Страшно?

Разберемся.

Нынче модная тема в жж - блокировка слов ru_politics, ru_nbp и еще нескольких.

Цензура, гэбня, удушение свободы слова ...

Некоторые "проводят исследования" и "выясняют масштабы" (на самом деле глупо пиарятся, собирая ссылки на свой журнал): http://insie.livejournal.com/231258.html?style=mine.

Раздаются здравые голоса, что это борьба с DDoS'ом и "цензуру" проводит простой пакетный фильтр, который просто сбрасывает пакеты с ключевыми словами: http://zhuzh.livejournal.com/365653.html.

Разберемся.