Po PLNOG 4.

Miałem ambitny plan pisania na bieżąco, ale w sumie głupio siedzieć na wykładzie i trochę słuchać, a trochę pisać – IMO lepiej się skupić na wykładzie. Z kolei między wykładami (i po) ciekawsze rzeczy do roboty były (choćby dyskusja o wykładzie).

Podobno na spotkaniu podsumowującym co zmienić w PLNOG pojawiły się głosy, że za dużo marketingu (znowu). Szczerze powiem, że w tym roku nie odczułem tego – udało mi się tak wybrać ścieżkę (większość czasu były trzy linie), że nie trafiłem na nieciekawy marketingowy wykład. A te, na których byłem, niosły IMO wystarczającą dawkę techniki (no, OK, czasem były raczej teaserem i o technice rozmowy były na korytarzu, ale bez jakiegoś niesmaku na wykładzie).

Organizacyjnie – podziwiam. Pewnie kwestia doświadczenia z poprzednich, ale wyciąganie wniosków to też sztuka, poza tym coraz więcej uczestników. Świetnie dobrana lokalizacja (nie było duszno, miejsca akurat), świetne zaplecze techniczne (dwa razy byłem świadkiem problemów z projektorem, dwa razy przerwy w wykładzie praktycznie nie było, a obsługa była na miejscu i wiedziała co robić i wykład był przywrócony w ok. minutę; działające wifi). Zobaczymy jak z lagiem dotyczącym opublikowania wykładów na stronie tym razem, ale było bardzo dobrze.

Jedno, co mi się nie do końca podobało (na zasadzie „po co to”, nie „przeszkadza”) to trochę za duża ilość konkursów (plus „kto pierwszy znajdzie litery i wpisze na twittera” zakładało niesłuchanie wykładu). Fajnie, że było jak się oderwać, ale IMO impreza nie jest aż tak nieciekawa, by ktoś miał na to czas. 😉 Jeśli było robione na zasadzie „jest czas i ktoś, kto nie ma nic innego do roboty chce zrobić” to super, jeśli nie – IMHO spokojnie można sobie odpuścić.

Chyba trochę nie wypalił pomysł z twitowaniem (wybór Twittera jest dość oczywisty – ludzie z zagranicy, a paru było, nie będą używać np. Blipa). Podejrzewam, że bardziej na skutek tego, co opisałem w pierwszym akapicie, niż braku info przed całą imprezą, że będzie stosowany jako kanał komunikacji. Poza tym, trochę trudno byłoby migrować się między prezentacjami, szczególnie, że nie były zbyt długie.

Po kolei wykładów omawiać nie będę, bo mają być niebawem do pobrania nagrania i prezenacje, więc krótkie wrażenia – jest realna odpowiedź na zagadnienia z pierwszego PLNOG. IPTV w Polsce, w wykonaniu małych firm, zaczyna wyglądać inaczej, niż wyobrażano to sobie wtedy. Zaczyna się partyzantka w postaci unicastu, niezarządzalnego sprzętu, radia, rozszytych kabli jako standardu, własnych CA. Znaczy się: pojawiły się takie rozwiązania. I dobrze, że są pomysły. Co z tego wyniknie? Zobaczymy. Druga duża zmiana, to nowa oferta TPSA. Było narzekanie, że nie ma peeringu, że drogo, że to userzy TPSA korzystają z contentu, a dostawca musi płacić TPSA za łącze… Peeringu nadal nie ma, ale jest odpowiedź ofertowa na – uchylone co prawda przez KE – zarzuty UKE. Trochę może to na rynku namieszać, oj może…

Ostatnie spostrzeżenie, dotyczące ostatnich kontrowersji z blokowaniem stron i „ustawą hazadową”. Dostawcy łącz wydają się być zgodni (o ile nie jednogłośni), że pewne rzeczy wycinać trzeba, natomiast wydają się dalecy od chęci blokowania inaczej, niż na podstawie przesłanek technicznych. Chętnie wytną/zaakceptują wycięcie domeny/IP/portu, bo używa tego malware, ale nie chcą się angażować w kwestie prawno-treściowe tj. nie chcą wyręczać sądu w ocenie, czy przesyłanie danego pliku jest legalne lub czy treści na danej stronie naruszają prawo. Blokowanie po IP/domenie było z kolei średnio do przyjęcia dla dostawców contentu (co się stanie, jak ktoś wrzuci „treści” na np. Allegro?).

Miło słyszeć, że blokada portu 25 w usługach opartych o Neostradę zakończyła się sukcesem. Wg danych z prezentacji nie korzysta z niej tylko ok. 1% abonentów. Jak to ładnie podkreślono „szlak został przetarty”.

Było ciekawie, inspirująco i mobilizująco – na pewno jest o czym myśleć, jest parę pomysłów na działania, jeśli tylko będą zasoby (czas, czas, czas…), to jest co robić.

Przepisy o retencji danych wchodzą w życie.

Jakiś czas temu pisałem o rozporządzeniu w sprawie retencji danych, jak można się było spodziewać, weszło ono w życie.

VaGla komentuje sprawę szerzej, natomiast mnie interesują zmiany, które zostały wprowadzone, z punktu widzenia administratora sieci ethernetowej.

Przede wszystkim pojawiło się piękne, wieloznaczne słowo lub. Chodzi o §6 rozporządzenia. Port sieciowy (na dodatek o zmienionej definicji), został przeniesiony z dotychczasowego punktu 1 d) w brzmieniu adres IP i numer wykorzystywanego portu sieciowego do punktu 1 f) w brzmieniu identyfikator zakończenia sieci, w którym użytkownik końcowy uzyskał dostęp do Internetu, w szczególności identyfikator cyfrowej linii abonenckiej DSL (Digital Subscriber Line), numer wykorzystywanego portu sieciowego lub adres MAC urządzenia końcowego inicjującego połączenie.

Czyli jeśli logujemy MAC adres (oczywiście nikt nie bierze pod uwagę, że po pierwsze to się zmienia, po drugie sporo kart zintegorwanych nie ma swojego natywnego MAC, po trzecie, że MAC adresy potrafią się – nawet sprzętowo – powtórzyć, ale nie wymagajmy za wiele), to nie trzeba logować portu.

Kolejna sympatyczna (w zasadzie nieunikniona) zmiana, to §14, mówiący o sześciomiesięcznym okresie dostosowawczym dla tych, którzy w dniu wejścia w życie nie spełniają wymagań rozporządzenia. Wejście w życie nie zostało zmienione – był nim 1 stycznia 2010 r.

Czyli ci, którzy nie spełniają wymogów rozporządzenia, mają przed sobą pracowite pół roku.

Szkoda tylko, że rozporządzenie nadal nie jest jasne. Część rzeczy wyjaśnia (albo zaciemnia) dopiero uzasadnienie. Przykładowo, jeśli chodzi o pocztę elektroniczną napisano Odnośnie usługi poczty elektronicznej podkreślić należy, że ustawa zalicza do usług telekomunikacyjnych przekazywanie poczty elektronicznej, a nie usługę poczty elektronicznej.

Zapraszam do uwag, szczególnie prawników i administratorów „osiedlówek” i sieci radiowych, zarówno tych większych, jak i tych mniejszych.

Retencja danych – przepisy wykonawcze.

Ustawa nakazująca operatorom przechowywanie danych o połączeniach istnieje od dawna, ale do tej pory dostawcy internetu robili, co mogli/chcieli, bo przepisów wykonawczych nie było. Wszystko wskazuje na to, że niebawem się to zmieni, bo Minister Infrastruktury przygotowuje rozporządzenie w tej sprawie. I nie wygląda ono różowo, szczególnie dla mniejszych ISP, opierających się o sieci ethernetowe, a ich także – obok dostawców telefonii i poczty elektronicznej – dotyczy.

Projekt rozporządzenia Ministra Infrastruktury w sprawie szczegółowego wykazu danych oraz rodzajów operatorów publicznej sieci telekomunikacyjnej lub dostawców publicznie dostępnych usług telekomunikacyjnych obowiązanych do ich zatrzymania i przechowywania, o którym piszę, można przeczytać w całości na stronach Ministerstwa Infrastruktury, podobnie jak dołączone do niego uzasadnienie. Gorąco polecam lekturę obu tych pism przed czytaniem reszty wpisu, a na pewno przed komentowaniem.

Pisać będę z punktu widzenia najbliższego mi, czyli dostawcy internetu i tylko na temat dostarczania usługi internetowej. Pocztę elektroniczną i telefony całkowicie pomijam, choć zdanie administratorów – szczególnie serwerów pocztowych – także mnie interesuje i zapraszam do komentowania.

Przede wszystkim wygląda, że ustawodawca albo zapomniał o istnieniu i zasadach działania sieci opartych o ethernet, albo w ogóle nie zdaje sobie sprawy, w jaki sposób one działają. Ruch w obrębie sieci rozgłoszeniowej w takiej sieci zamykać się może w obrębie jednego przełącznika. Switche są różne, ale nawet te zarządzalne rzadko kiedy oferują wsparcie dla logowania czegokolwiek wymaganego w ustawie. O logowaniu połączeń między użytkownikami dostawcy korzystający ze switchy niezarządzalnych mogą całkiem zapomnieć. Oczywiście, można podzielić sieć na mniejsze (dla każdego użytkownika osobna sieć), ale w ten sposób po pierwsze bardziej obciąża się router, po drugie traci się największą zaletę takiej sieci, jaką jest decentralizacja ruchu lokalnego.

W rozporządzeniu brakuje definicji połączenia. O ile w przypadku telefonii sprawa jest dość oczywista i można ją traktować „na chłopski rozum’, o tyle w przypadku Internetu nie jest tak prosto, szczególnie, że istnieją protokoły bezpołączeniowe. Czy każdy pojedynczy wysłany pakiet traktować wówczas jako połączenie? Co traktować jako rozpoczęcie połączenia? Co jako zakończenie połączenia? W której warstwie modelu OSI należy badać połączenie?

Zauważyć należy, że rozporządzenie wprowadzać ma obowiązek logowania portów. W uzasadnieniu można przeczytać, że dotychczasowa praktyka wskazuje, że obecnie w większości przypadków operatorzy posiadają te dane i nie są one specjalnie generowane w celu retencji ale nie wierzę, że mowa w tym przypadku o portach. O ile większość mi znanych małych ISP jest w stanie określić IP użytkownika i ew. aktywność o zadanej porze, o tyle z portami sprawa ma się zupełnie inaczej (faktem jest, że służby praktycznie nigdy o to nie pytają).

Błędem jest też zapis, że port sieciowy określa rodzaj usługi komunikacyjnej w sieci teleinformatycznej. Istnieją oczywiście pewne zalecenia i standardy, ale port ani nie definiuje usługi, ani usługa nie definiuje portu. Nie ma żadnego problemu w wykorzystaniu nietypowego portu dla danej usługi, co więcej, stosunkowo często jest to stosowane (choćby jako redukcja zagrożenia ze strony skanerów szukających podatności w danych usługach).

Ciekawe jest też wymaganie określenia momentu nawiązania połączenia i rozłączenia z Internetem, także w przypadku adresacji statycznej. Oczywiście definicji Internetu brakuje… Co w przypadku popularnego wśród mniejszych operatorów DHCP, gdzie rozpoczęcie owszem, łatwo określić, ale koniec już nie bardzo…

Ostatnia niefortunna rzecz to – moim zdaniem – termin, od kiedy rozporządzenie miałoby zacząć obowiązywać. Planowaną datą jest bowiem 1 stycznia 2010 r., co praktycznie nie daje mniejszym operatorom możliwości dostosowania się do niego, także po doprecyzowaniu ww. nieścisłości.

Szczerze mówiąc, ciekaw jestem opinii, szczególnie administratorów mniejszych, opartych o ethernet sieci, na temat tego projetku. Chętnie też poznam uwagi na temat ew. błędów w mojej interpretacji ww. rozporządzenia.