OPINIA Polskiej Izby Informatyki i Telekomunikacji [PIIT]

Transkrypt

1

2 OPINIA Polskiej Izby Informatyki i Telekomunikacji [PIIT] z dnia 27 maja 2011 roku dotycząca projektu rozporządzenia Rady Ministrów w sprawie wymagań technicznych i eksploatacyjnych dla interfejsów umoŝliwiających wykonywanie zadań i obowiązków na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego. Po zapoznaniu się z projektem Rozporządzenia Rady Ministrów w sprawie wymagań technicznych i eksploatacyjnych dla interfejsów umożliwiających wykonywanie zadań i obowiązków na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego (dalej projektu rozporządzenia) niniejszym PIIT przedstawia swoją opinię dotyczącą projektu rozporządzenia: W świetle proponowanego uregulowania proponowane zapisy są nie do przyjęcia przez operatorów telekomunikacyjnych sieci mobilnych i stacjonarnych. 1. Z uwagi na skalę proponowanych zmian, oraz istotność regulowanej materii, wskazane jest aby przedmiotowe rozporządzenie zapewniało trwałości obecnie funkcjonujących rozwiązań. W projekcie rozporządzenia powinien znaleźć się zapis zwalniający operatorów którzy już posiadają zawarte porozumienia z podmiotami uprawnionymi na udostępnianie treści przekazów telekomunikacyjnych za pośrednictwem interfejsów z obowiązku posiadania rozwiązania zgodnego z proponowaną w nowelizacji specyfikacją. Brak zapisu o bezwarunkowym dopuszczeniu do dalszego użytkowania rozwiązań, które funkcjonują już teraz trudno odczytać inaczej, jak swego rodzaju sankcję nałożoną na tych operatorów, którzy wychodząc naprzeciw potrzebom Państwa zainwestowali olbrzymie środki (zarówno finansowe, jak i ludzkie) w wypracowanie, uzgodnienie a następnie zaimplementowanie interfejsu. Podkreślić trzeba, że konieczność dostosowania obecnie użytkowanych rozwiązań do proponowanego rozporządzenia będzie zmuszała operatorów do rozważenia czy ponosić dalsze koszty dostosowywania i utrzymywania interfejsu, czy też powrócić do sytuacji sprzed kilku lat, kiedy nie było interfejsów. Nie ulega wątpliwości, że w przypadku wyłączenia interfejsów najbardziej zmianę tę odczują podmioty uprawnione, które inwestowały olbrzymie publiczne środki w budowę systemów, które teraz trzeba będzie albo zmienić, albo wręcz w niektórych obszarach wyłączyć. Warto też zauważyć, że w przypadku, gdy operator jednak zdecyduje się na dostosowanie systemu do nowych wymagań, to i tak przez okres kilku miesięcy (czas na przebudowę i ponowną certyfikacji systemu) podmioty uprawnione, które już teraz mają podpisane stosowne porozumienia, zostaną pozbawione możliwości korzystania z interfejsu. Aby uniknąć wyżej opisanych problemów wystarczy zapisać w rozporządzeniu, że specyfikacja dotyczy wyłącznie interfejsu do tych podmiotów, które w chwili wejścia w życie rozporządzenia nie miały podpisanego porozumienia, o którym mowa w art. 179 ust 4a. 2. Istnieje uzasadniona obawa czy opisany w załącznikach interfejs jest w ogóle możliwy do zaimplementowania oraz czy będzie funkcjonował w sposób prawidłowy. Obawa wynika z faktu, iż w projekcie rozporządzenia znajduje się szereg istotnych błędów (wskazanych poniżej w uwagach szczegółowychj). Nie bez znaczenie jest fakt, iż na etapie tworzenia specyfikacji pominięto etap konsultacji z operatorami, którzy bez wątpienia dysponują zarówno wiedzą teoretyczną, ale również praktyczną (w zakresie projektowania, wdrażania i bieżącej obsługi interfejsów). Ponadto zakładany okres vacatio legis jest nie do przyjęcia, ponieważ okres niezbędny jest co najmniej 36 miesięczny okres na procedury budżetowania, zamawiania, wdrożenia oraz akredytacji w ABW systemów Lawfull Interception. Strona1 Opinia PIIT w sprawie projektu rozporządzenia RM Art. 182 PT

3 3. Jesteśmy zdania, że projekt rozporządzenia nie spełnia warunku zawartego w delegacji ustawowej z art. 182 PT i przy określaniu wymagań eksploatacyjnych nie uwzględniono ustawowego wymogu kierowania się zasadą minimalizacji nakładów przedsiębiorcy telekomunikacyjnego i podmiotów uprawnionych : - nie uwzględniono aktualnego stanu technologicznego i kierunków jego rozwoju w zakresie dostępnych funkcjonalności LI dla poszczególnych generacji telefonii komórkowej (np.: LTE, Voice over LTE), a także konwergencji usług np. przenikanie się sieci mobilnych i stacjonarnych tak jak świadczenie usług sieci stacjonarnej z wykorzystaniem sieci ruchomej. Nie wzięto pod uwagę możliwości stosowania innych, nowoczesnych identyfikatorów użytkowników, jako kryteriów wyboru obiektu obserwacji np. ENUM. Budowane wg zaproponowanej w projekcie specyfikacji interfejsów systemy LEMF i ADMF z założenia będą przestarzałe technologicznie już w trakcie ich budowy. - pominięto potrzebę unifikacji rozwiązań systemowych budowanych na potrzeby uprawnionych podmiotów oraz na potrzeby sądów i prokuratorów (np. możliwość przekazywania postanowień prokuratorskich w postaci elektronicznej styk HI1 interfejsu HI i interfejs HI A-B), powodując tym samym zwiększenie kosztów ponoszonych przez przedsiębiorcę telekomunikacyjnego. - Rozumiejąc,że w warstwie technologicznej niezbędna jest identyfikacja uprawnionego podmiotu pragniemy podkreślić,że format LIID identyfikuje jednoznacznie uprawniony podmiot, co jest sprzeczne z wymaganiami ABW stawianymi przedsiębiorcom telekomunikacyjnym w procesie akredytacji systemów zaimplementowanie dodatkowych mechanizmów anonimizacji LIID w sieci telekomunikacyjnej stanowi dodatkowy, koszt po stronie przedsiębiorców telekomunikacyjnych.piit uważa ze wymagania w zakresie konstruowania black box winny zostać wyraźnie określone w rozporządzeniu w taki sposób, aby ochrona informacji nie powodowała nadmiernych kosztów. - rozporządzenie w pkt. IV.1.8 załącznika nr 1 nakłada na przedsiębiorcę telekomunikacyjnego nowy obowiązek buforowania (przechowywania przez 72 godziny i przetwarzania) treści kontrolowanych przekazów telekomunikacyjnych na wypadek wystąpienia awarii powodującej brak transmisji pomiędzy ADMF a LEMF, budzi to zasadnicze wątpliwości prawne czy nie przekracza to zakresu delegacji ustawowej i czy operator telekomunikacyjny jest na podstawie ustawy uprawniony do zatrzymywania tych treści? może to wskazywać także na to, że obowiązek zapewnienia właściwego poziomu dostępności w systemach LEMF do udostępnionych treści przekazów telekomunikacyjnych przerzucony został na przedsiębiorców telekomunikacyjnych, co wpływa na znaczne podwyższenie kosztów ponoszonych przez tych przedsiębiorców, buforowanie winno być, co najwyżej opcją dopuszczalna wyłącznie z przyczyn technicznych, ale dopuszczać stosowanie innych rozwiązań zabezpieczających. 4. Projekt rozporządzenia nie uwzględnia rozwiązań interfejsowych przygotowanych przed dniem wejścia w życie ustawy z dnia 24 kwietnia 2009 r. o zmianie ustawy Prawo telekomunikacyjne oraz niektórych innych ustaw, spełniających wymagania określone w art. 179 ust. 4-4b i art. 180d Prawa telekomunikacyjnego. Możliwość stosowania i eksploatacji takich rozwiązań została dopuszczona na mocy art. 15 ust. 1 powołanej wyżej ustawy z dnia 24 kwietnia 2009 r. Należy przy tym zaznaczyć, że w latach , gdy uprawnione podmioty budowały systemy LEMF nowej generacji, specyfikacja interfejsów dot. tych systemów została uzgodniona z przedsiębiorcami telekomunikacyjnymi oraz interfejsy te zostały przetestowane, a następnie systemy posiadające uzgodnione interfejsy zostały akredytowane przez ABW i wdrożone do eksploatacji. Strona2 Opinia PIIT w sprawie projektu rozporządzenia RM Art. 182 PT

4 5. Projekt nie uwzględnia standardu IPv6, co może spowodować konieczność różnego rodzaju mechanizmów opakowania IPv6 w IPv4 co skomplikuje i podwyższy koszty budowy interfejsów również ze względu na kończący się zapas adresów. 6. Ponadto w projekcie rozporządzenia znalazło się wiele zapisów, które wymagają doprecyzowania lub zmiany gdyż w obecnym stanie budzą poważne zastrzeżenia: a. w projekcie przedmiotowego rozporządzenia znajduje się aż 21 odwołań do różnych, (wymienionych w pkt I załącznika nr 1 do rozporządzenia), dokumentów nie funkcjonujących w polskim porządku prawnym. Standardy te winny zostać wcześniej wymienione przez ministra właściwego do spraw łączności na mocy delegacji zawartej w art. 3 ust. 3 Prawa telekomunikacyjnego ( por. S. Piątek, komentarz do PT, str.143, wyd.2005). b. projektodawca dokładnie specyfikując kodeki i format plików audio i wideo wymusza ingerencję przedsiębiorcy telekomunikacyjnego w treść przekazu telekomunikacyjnego mającą wpływ na jego jakość (w sieciach czwartej generacji (Rel.4) często stosowane są inne kodeki niż wskazany kodek G.711A). Zamknięta lista kodeków wideo wydaje się również niewłaściwym rozwiązaniem ponieważ wyklucza nowsze rozwiązania w przyszłości. Ponadto zgodnie z proponowanym w punkcie 4.3 a) formatem nazewnictwa plików nie da się stwierdzić czy dany plik zawiera voice czy video. Powinno być zastosowane jakieś inne rozszerzenie do plików wideo. Również dla operatorów telefonii stacjonarnej, na skutek dużego wolumenu ruchu oraz różnorodności usług, wprowadzenie proponowanego standardu interfejsu wiązać się będzie z koniecznością przebudowy sieci, baz danych oraz istniejących systemów LI. Ze względu na już przyjęte rozwiązania (często chronione patentami), wolumen i architekturę sieci przebudowa systemu wiązać się będzie z bardzo dużymi kosztami po stronie operatora i nie będzie mogła być wykonana w nakazanym czasie. W załączeniu przekazujemy szczegółowe uwagi Telekomunikacji Polskiej, jako egzemplifikację tego problemu (Załącznik nr 2 do stanowiska ) które Polska Izba Informatyki i Telekomunikacji zdecydowanie popiera. Przepis art. 182 Ustawy prawo telekomunikacyjne z 2004 r. stanowi delegację dla wydania rozporządzenia przez Radę Ministrów, które określać ma wymagania techniczne i eksploatacyjne dla interfejsów, o których mowa w art. 179 ust. 4a PT umożliwiających wykonywanie zadań i obowiązków na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego. Mimo, że obowiązek wydania takiego rozporządzenia przez Radę Ministrów został określony w ustawie z 2004 r., to do chwili obecnej przedmiotowe rozporządzenie nie zostało wydane. Wobec braku aktu prawnego regulującego standardy dla realizacji interfejsów, a w ślad za tym braku możliwości świadczenia obowiązków na rzecz obronności i bezpieczeństwa za pomocą interfejsów, trzech operatorów sieci ruchomej (PTK Centertel, PTC, Polkomtel), z własnej inicjatywy podjęło prace zmierzające do opracowania specyfikacji interfejsu. Specyfikacja została wypracowana w konsultacji z zainteresowanymi podmiotami uprawnionymi i umożliwiła wykonywanie określonych przez Ustawę PT zadań i obowiązków w zakresie obronności i bezpieczeństwa przy pomocy interfejsów. Wypracowana i uzgodniona specyfikacja została wykorzystana w porozumieniach/umowach zawieranych w latach na podstawie przepisów Ustawy PT - przez przedsiębiorców telekomunikacyjnych z podmiotami uprawnionymi oraz jest nadal wykorzystywana w umowach aktualnie negocjowanych z kolejnymi podmiotami. Strona3 Opinia PIIT w sprawie projektu rozporządzenia RM Art. 182 PT

5 Należy przy tym podkreślić, że w celu wdrożenia ww. umów, przedsiębiorcy telekomunikacyjni ponieśli znaczne nakłady (w szczególności duże nakłady zostały poniesione na budowę systemów implementujących interfejs zgodnie z opracowaną specyfikacją). Uwzględniając powyżej opisane okoliczności (już istniejąca specyfikacja interfejsu i koszty poniesione w związku z jej implementacją), postulujemy, by projekt Rozporządzenia sankcjonował już podpisane porozumienia pomiędzy przedsiębiorcami telekomunikacyjnymi i podmiotami uprawnionymi i przyjętą w tych porozumieniach specyfikację interfejsów. Postulujemy, by w Rozporządzeniu znalazł się przepis, który przewiduje, że wszyscy przedsiębiorcy telekomunikacyjni, którzy już wykonują za pomocą interfejsów zadania i obowiązki na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego, zwolnieni zostali z obowiązku posiadania rozwiązania zgodnego z nową specyfikacją wprowadzaną przedmiotowym Rozporządzeniem albo, aby uelastycznić treść rozporządzenia w taki sposób, aby istniejące rozwiązania mogły się w nim zmieścić. W naszej ocenie, przedsiębiorcy, którzy już posiadają lub negocjują porozumienia/umowy z podmiotami uprawnionymi powinni mieć zagwarantowaną możliwość stosowania interfejsu w wersji już uzgodnionej i zaakceptowanej przez strony umowy (przedsiębiorcę telekomunikacyjnego i podmiot uprawniony) bez konieczności migrowania na interfejsy o nowej specyfikacji, którą narzuca projekt Rozporządzenia. Taka migracja wymuszałaby na operatorach ponoszenie dodatkowych kosztów i de facto karałaby tych operatorów, którzy - wobec próżni prawnej - podjęli dobrowolną (i na własny koszt) inicjatywę wypracowania standardów interfejsów, stwarzając tym samym warunki do realizacji zadań na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego. Z uwagi na harmonogramy budżetowania środków u przedsiębiorców telekomunikacyjnych, czas niezbędny na opracowania, projekt i wdrożenia zmian oraz wielomiesięczny proces certyfikacji rozwiązania przez ABW, konieczne jest zapewnienia odpowiedniego okresu na wejście w Rozporządzenia w życie. Postulujemy, by vacatio legis dla rozporządzenia wynosiło 36 miesięcy. Do stanowiska dołączamy listę uwag szczegółowych operatorów mobilnych odnoszących się do konkretnych zapisów zawartych w załącznikach do rozporządzenia (Załącznik nr 1 do stanowiska PIIT). Polska Izba Informatyki i Telekomunikacji [PIIT] wyraża zdecydowanie negatywne stanowisko wobec przedmiotowego projektu rozporządzenia, którego bezkrytyczna implementacja może narazić Państwo paraliż funkcji związanych z LawfullOpin Interception a operatorów na gigantyczne koszty. Jednocześnie deklarujemy gotowość naszych ekspertów w uczestnictwie w pracach nad zmianami w rozporządzeniu. II. Załącznik nr 1 Szczegółowe uwagi operatorów mobilnych odnoszących się do załączników do projektu rozporządzenia : W ocenie PIIT specyfikacja zawarta w obecnym projekcie rozporządzenia zawiera szereg błędów, co budzi poważną obawę i wątpliwości o techniczną możliwość implementacji interfejsu o tak zdefiniowanej specyfikacji i jego prawidłowe działanie. PIIT pragnie odnotować, że na etapie tworzenia specyfikacji interfejsu nie przeprowadzono konsultacji z operatorami, którzy bez wątpienia są ekspertami w tej dziedzinie i dysponują Strona4 Opinia PIIT w sprawie projektu rozporządzenia RM Art. 182 PT

6 zarówno wiedzą teoretyczną, ale również praktyczną (w zakresie projektowania, wdrażania i bieżącej obsługi interfejsów). Uwagi szczegółowe do załączników: 1. Dot. załącznika nr 1 do projektu rozp. wymagania techniczne i eksploatacyjne a. Rozdział III (określenia użyte w załącznikach oznaczają): - W definicji w pkt 3 (obiekt monitorowany) należy usunąć słowa użytkownik lub abonent. b. Rozdział IV (Interfejs LI HI) - pkt 1.1 zamiast 1000BASE-T zapisać 100/1000BASE-T - pkt 1.2 zamiast wymagane zapisać zalecane - pkt 1.3 należy doprecyzować o jaki protokół chodzi - pkt 1.6 proponujemy nowe brzmienie całego punktu, zgodne z obowiązującą specyfikacją LIHI na której wzorował się ustawodawca: LIID dla danego typu obiektu (MSISDN, IMEI itp.) zawiera tylko jedna usługę do monitorowania (jedna usługa per LIID). Jeśli obiekt będzie wymagał monitorowania kilku usług, system LEMF powinien za każdym razem przydzielić nowe LIID. Z punktu widzenia użytkownika systemu LEMF nie powinno to przysparzać problemów z gromadzeniem treści różnych usług dla jednego monitorowanego obiektu - pkt 2.3 i 2.4 zamiast obu punktów proponujemy umieszczenie tabeli (macierzy) pokazującej, jakie kryteria obserwacji (parametry) mogą wystąpić w każdej z usług - pkt 2.4, lit. c - zamiast dostęp do internetu powinno być zapisane usługi dostępu do internetu np.: wlan, dsl - pkt 2.4, lit. d - brak w 2.3 kryteriów monitorowania dla IMSa - pkt 2.6 punkt wewnętrznie sprzeczny skutkujący brakiem możliwości implementacji rozporządzenia w systemie operatora - pkt 2.9 brak technicznych możliwości realizacji takiego wymagania w systemie operatora. Dodatkowo zapis wykracza poza obowiązki określone w ustawie prawo telekomunikacyjne - pkt 2.10 brak technicznej możliwości realizacji takiego wymagania w systemie operatora. Dodatkowo zapis wykracza poza obowiązki określone w ustawie prawo telekomunikacyjne - pkt 2.12 zapis w obecnym kształcie stanowi bardzo poważne zagrożenie bezpieczeństwa, w tym związane z ujawnieniem celu (obiektu monitorowanego) należy usunąć słowa włączenia/wyłączenia trybu online oraz - pkt 3.2 wskazany standard ETSI dotyczy tylko usług mobilnych; należy sprawdzić, czy faktycznie wyłącznie dla usług mobilnych ma być realizowane to wymaganie - pkt 3.4 należy określić jakie są dopuszczalne wartości pola z nazwą rozszerzenia - ext - pkt 4.3 podział na online i offline ma tylko zastosowanie dla usług rozmów głosowych w sieciach mobilnych; - pkt 4.4 wskazana norma nie dotyczy ULIC c. Rozdział V (interfejs HI A-B) - pkt 1.3 zamiast LI HI powinno być HI A-B. - Strona5 Opinia PIIT w sprawie projektu rozporządzenia RM Art. 182 PT

7 III.Uwagi do załącznika nr 2 do projektu rozporządzenia specyfikacja elementów interfejsu HI1 - pkt należy usunąć zapis dot. RTRequest - pkt należy usunąć Dopuszcza się wysłanie zlecenia aktywacji z pewnym wyprzedzeniem, gdyż taki zapis jest sprzeczny z punktem pkt zapis jest sprzeczny z punktem pkt brak zdefiniowanych wymaganych minimalnych parametrów kryptograficznych długości klucza, algorytmy - załączone struktury ASN.1 są niepoprawne i nie kompilują się np. UnsignedRequestDetail (specyfikacja ASN.1 dla UnsignedRequestDetail) skutkuje to brakiem możliwości implementacji w systemie operatora, co z kolei będzie skutkować koniecznością wyłączenia interfejsu i powrotu do bezinterfejsowego obsługiwania wniosków podmiotów uprawnionych - W strukturach ASN.1 usunięto komentarze, które są niezbędne do właściwego i jednoznacznego zaimplementowania w systemie operatora wymagań określonych w rozporządzeniu - Brak określonego sposobu kodowania dla parametrów takich jak MSISDN, IMSI np. w UsnignedRequestDetail, strona 15 - Umieszczony w strukturze ASN.1 Regon (strona 22) powinien być opcjonalny Załącznik numer 2 do stanowiska PIIT dot. projektu rozporządzenia Rady Ministrów. Stanowisko Telekomunikacji Polskiej S.A. do projektu rozporządzenia Rady Ministrów w sprawie wymagań technicznych i eksploatacyjnych dla interfejsów umożliwiających wykonywanie zadań i obowiązków na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego (w wersji przekazanej przez Ministerstwo Infrastruktury do uzgodnień międzyresortowych). Analiza treści rozporządzenia nieodparcie nasuwa wnioski, ze jego autorzy oparli się o doświadczenia związane z implementacją interfejsów przez operatorów GSM. U operatorów GSM implementacja LIU jest inna np. poprzez pola komutacyjne central czy inne elementy sieci. Nieporównywalne są także wolumeny ruchu w sieci stacjonarnej w odniesieniu do transmisji danych w kanale radiowym jak i różnorodność usług. W związku z powyższym uwagi Telekomunikacji Polskiej odnoszą się do takich fragmentów rozporządzenia, które należy zmienić w odniesieniu do operatorów stacjonarnych, aby była możliwe podjęcie prac w celu wdrożenia interfejsu. Pozostawienie rozporządzenia w takim kształcie w ocenie TP przekreśla możliwość podjęcia prac nad zinterfejsowaniem systemów TP według proponowanego standardu ze względu na już przyjęte rozwiązania /często chronione patentami/, określoną architekturę sieci itp. Należy również dopuścić możliwość podpisania umowy z zainteresowanymi służbami np. na implementację interfejsu H1, H2, H3 /Legal Intercept/ bez konieczności implementacji interfejsu HI A-B. Strona6 Opinia PIIT w sprawie projektu rozporządzenia RM Art. 182 PT

8 W razie nieuwzględnienia poniższych uwag w przypadku sieci PSTN i Internet implementacja interfejsu jest praktycznie niewykonalna bez przebudowy sieci, baz danych, systemów Legal Interception. Uwagi szczegółowe: - IV pkt Bezwzględnie należy uwzględnić IPv6.(to samo dla punktu V p1.3) Uzasadnienie: - Cała sieć TP (i prawdopodobnie wszyscy inni operatorzy) przechodzi niedługo na IPv6 z powodu kończenia się puli adresów IPv4; w związku z tym wprowadzenie na interfejsie tylko IPv4 może spowodować konieczność wprowadzenia różnego rodzaju mechanizmów opakowywania IPv6 w IPv4, co skomplikuje (zapewnienie niezmienności monitorowanych danych i ich integracji) i podwyższy koszt całego przedsięwzięcia. - IV pkt 2.2 za podpunktem d - należy dodać lit. e) parametr okres monitorowania. - IV pkt 2.3a należy dodać do zestawienia skrót VoIP. - IV pkt 2.5a Może istnieć problem w monitorowaniu IRI + SMS. Uzasadnienie: W sieci TP SMS jest inaczej przesyłany niż w sieciach operatorów mobilnych i może istnieć możliwość ich monitorowania jedynie w trybie IRI + CC - IV pkt 2.9 wskazanie sposobu określenia zasięgu, jako przesłanie numerów central, nie ma sensu dla usług, których realizacja nie opiera się o centrale; należy ten fragment wykreślić, chyba istotną informacją jest, kto w danym momencie nie może być monitorowany a nie, który element sieci uległ awarii - a co z numerami przeniesionymi?. Ten punkt trzeba uściślić, czy chodzi o przypadki awarii sieci operatora czy elementów systemu monitoringu? - IV pkt W przypadku, kiedy warunki techniczne usługi nie zezwolą na monitorowanie jej przy użyciu interfejsu LI HI w trybie automatycznym, zgoda Uprawnionego Podmiotu na realizację jej w trybie półautomatycznym powinna zawierać ustalone timeouty dotyczące czasu realizacji, ustanowienia monitorowania, które będą obowiązywać wszystkie służby. W związku z różnorodnością platform VoIP i systemów dostępu do Internetu /ATM, GBE/ wystąpi konieczność weryfikacji w niektórych przypadkach konfiguracji abonenta lub wykonania prac przygotowawczych. W związku z powyższym preferowany będzie w TP tryb półautomatyczny pracy interfejsu dla usług internetowych. TP proponuje w związku z powyższym zapisanie w rozporządzeniu lub załączniku, z którym Uprawnionym Podmiotem jedynym i wskazanym, operator będzie musiał uzgodnić szczegóły pracy w trybie półautomatycznym i które to uzgodnienia będą wiążące dla pozostałych Uprawnionych Podmiotów. Uzasadnienie: - Zapis w punkcie 2.15 wskazuje, że każdy Uprawniony Podmiot musi wyrazić zgodę na realizację w trybie półautomatycznym. W związku z tym dla operatora możliwe są dwa warianty: Uprawniony Podmiot godzi się na tryb półautomatyczny na warunkach (timeouty) operatora lub monitoring danej usługi jest realizowany w sposób tradycyjny. Uprawnione Podmioty/Służby/ dysponują bardzo różnymi rozwiązaniami i platformami; jeżeli więc operator będzie musiał uzgadniać ten tryb pracy każdorazowo przed podpisaniem porozumienia z każdym Uprawnionym Podmiotem oddzielnie to będzie to proces kosztowny, długotrwały, nieefektywny. - IV pkt 3.1 czas na przesłanie danych skojarzonych z przekazem do 10 minut jest nie realny i nie jest do przyjęcia. TP proponuje czas do 24 godzin i doprecyzowanie pojęcia dane skojarzone lub ograniczenie ich do telefonii. Strona7 Opinia PIIT w sprawie projektu rozporządzenia RM Art. 182 PT

9 Uzasadnienie: W TP rozmowy w technologii VoIP są bilingowane w systemie kolekcji danych, gdzie proces przetwarzania danych trwa do 8 godzin, a z kolei dane o sesji internetowej są on-line dostępne tylko w systemie Radius i w zasadzie niczego nie wnoszą poza tym, ze klient ma włączony modem i jest zalogowany do sieci. Systemy monitorowania ruchu internetowego w TP nie korzystają z Radiusa/systemu autentykacji/ lecz wykorzystują inne parametry jednoznacznie identyfikujące abonenta. Tak krótki czas nie ma także uzasadnienia operacyjnego gdyż w naszej ocenie najważniejsza jest treść danych obiektu monitorowanego a ponieważ dane są transferowane on-line to Uprawniony Podmiot ma możliwość uzyskania wszelkich danych poprzez analizę treści czy czasu rozpoczęcia czy zakończenia transferu danych poprzez interfejs HI3. - IV pkt W sieci TP tylko jeden z systemów (VoIP) koduje dane w systemie ASN.1, dla pozostałych systemów dane są pobierane ręcznie z systemów kolekcji należy dopuścić za porozumieniem stosowanie formatu.txt, należy uszczegółowić, co to są dane skojarzone, jeśli chodzi o dostęp do Internetu. - IV pkt 4.1 zapis jest niejednoznaczny. Czy dotyczy całości treści sesji, czy pojedynczych ramek (w przypadku usług dostępu do Internetu) czego przekazu? - V pkt 1.3 dopisać IPv6 systemy Służb muszą być gotowe na IPv6. - V pkt 1.6 dopuścić format.txt. ASN1 nie jest stosowany poza jednym systemem w TP, przebudowa systemów byłaby kosztowna. Strona8 Opinia PIIT w sprawie projektu rozporządzenia RM Art. 182 PT

10

11 Warszawa, dnia 20. maja 2011 r. Stanowisko Telekomunikacji Polskiej S.A. do projektu rozporządzenia Rady Ministrów w sprawie wymagań technicznych i eksploatacyjnych dla interfejsów umoŝliwiających wykonywanie zadań i obowiązków na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego (w wersji przekazanej przez Ministerstwo Infrastruktury do uzgodnień międzyresortowych). Wstęp Analiza treści rozporządzenia nieodparcie nasuwa wnioski, ze jego autorzy oparli się o doświadczenia związane z implementacją interfejsów przez operatorów GSM. Operatorzy GSM posiadający w miarę jednorodną sieć i typy central oraz świadczący swoje usługi w oparciu o systemy centralowe nie są dobrym punktem odniesienia dla operatorów stacjonarnych. U operatorów GSM implementacja LIU jest stosunkowo prosta np. poprzez pola komutacyjne central czy inne elementy sieci. Nieporównywalne są takŝe wolumeny ruchu w sieci stacjonarnej w odniesieniu do transmisji danych w kanale radiowym jak i róŝnorodność usług. W związku z powyŝszym uwagi Telekomunikacji Polskiej odnoszą się do takich fragmentów rozporządzenia, które naleŝy zmienić w odniesieniu do operatorów stacjonarnych, aby była moŝliwe podjęcie prac w celu wdroŝenia interfejsu. Pozostawienie rozporządzenia w takim kształcie w ocenie TP przekreśla moŝliwość podjęcia prac nad zinterfejsowaniem systemów TP według proponowanego standardu ze względu na juŝ przyjęte rozwiązania /często chronione patentami/, określoną architekturę sieci itp. NaleŜy równieŝ dopuścić moŝliwość podpisania umowy z zainteresowanymi słuŝbami np. na implementację interfejsu H1, H2, H3 /Legal Intercept/ bez konieczności implementacji interfejsu HI A-B. W razie nieuwzględnienia poniŝszych uwag w przypadku sieci PSTN i Internet implementacja interfejsu jest praktycznie niewykonalna bez przebudowy sieci, baz danych, systemów Legal Intercept. Uwagi szczegółowe. 1. IV pkt Bezwzględnie naleŝy uwzględnić IPv6.(to samo dla punktu V p1.3) 1

12 Uzasadnienie: Cała sieć TP (i prawdopodobnie wszyscy inni operatorzy) przechodzi niedługo na IPv6 z powodu kończenia się puli adresów IPv4; w związku z tym wprowadzenie na interfejsie tylko IPv4 moŝe spowodować konieczność wprowadzenia róŝnego rodzaju mechanizmów opakowywania IPv6 w IPv4, co skomplikuje (zapewnienie niezmienności monitorowanych danych i ich integracji) i podwyŝszy koszt całego przedsięwzięcia. 2. IV pkt 2.2 za podpunktem d - naleŝy dodać lit. e) parametr okres monitorowania. 3. IV pkt 2.3a naleŝy dodać do zestawienia skrót VoIP. 4. IV pkt 2.5a MoŜe istnieć problem w monitorowaniu IRI + SMS. Uzasadnienie: W sieci TP SMS jest inaczej przesyłany niŝ w sieciach operatorów mobilnych i moŝe istnieć moŝliwość ich monitorowania jedynie w trybie IRI + CC 5. IV pkt 2.9 wskazanie sposobu określenia zasięgu, jako przesłanie numerów central, nie ma sensu dla usług, których realizacja nie opiera się o centrale; naleŝy ten fragment wykreślić, chyba istotną informacją jest, kto w danym momencie nie moŝe być monitorowany a nie, który element sieci uległ awarii - a co z numerami przeniesionymi?. Ten punkt trzeba uściślić, czy chodzi o przypadki awarii sieci operatora czy elementów systemu monitoringu? 6. IV pkt W przypadku kiedy warunki techniczne usługi nie zezwolą na monitorowanie jej przy uŝyciu interfejsu LI HI w trybie automatycznym, zgoda Uprawnionego Podmiotu na realizację jej w trybie półautomatycznym powinna zawierać ustalone timeouty dotyczące czasu realizacji, ustanowienia monitorowania, które będą obowiązywać wszystkie słuŝby. W związku z róŝnorodnością platform VoIP i systemów dostępu do Internetu /ATM, GBE/ wystąpi konieczność weryfikacji w niektórych przypadkach konfiguracji abonenta lub wykonania prac przygotowawczych. W związku z powyŝszym preferowany będzie w TP tryb półautomatyczny pracy interfejsu dla usług internetowych. TP proponuje w związku z powyŝszym zapisanie w rozporządzeniu lub załączniku, z którym Uprawnionym Podmiotem jedynym i wskazanym, operator będzie musiał uzgodnić szczegóły pracy w trybie półautomatycznym i które to uzgodnienia będą wiąŝące dla pozostałych Uprawnionych Podmiotów. Uzasadnienie: Zapis w punkcie 2.15 wskazuje, Ŝe kaŝdy Uprawniony Podmiot musi wyrazić zgodę na realizację w trybie półautomatycznym. W związku z tym dla operatora 2

13 moŝliwe są dwa warianty: Uprawniony Podmiot godzi się na tryb półautomatyczny na warunkach (timeouty) operatora lub monitoring danej usługi jest realizowany w sposób tradycyjny. Uprawnione Podmioty/SłuŜby/ dysponują bardzo róŝnymi rozwiązaniami i platformami; jeŝeli więc operator będzie musiał uzgadniać ten tryb pracy kaŝdorazowo przed podpisaniem porozumienia z kaŝdym Uprawnionym Podmiotem oddzielnie to będzie to proces kosztowny, długotrwały, nieefektywny. 7. IV pkt 3.1 czas na przesłanie danych skojarzonych z przekazem do 10 minut jest nie realny i nie jest do przyjęcia. TP proponuje czas do 24 godzin i doprecyzowanie pojęcia dane skojarzone lub ograniczenie ich do telefonii. Uzasadnienie: W TP rozmowy w technologii VoIP są bilingowane w systemie kolekcji danych, gdzie proces przetwarzania danych trwa do 8 godzin, a z kolei dane o sesji internetowej są on-line dostępne tylko w systemie Radius i w zasadzie niczego nie wnoszą poza tym, ze klient ma włączony modem i jest zalogowany do sieci. Systemy monitorowania ruchu internetowego w TP nie korzystają z Radiusa/systemu autentykacji/ lecz wykorzystują inne parametry jednoznacznie identyfikujące abonenta. Tak krótki czas nie ma takŝe uzasadnienia operacyjnego gdyŝ w naszej ocenie najwaŝniejsza jest treść danych obiektu monitorowanego a poniewaŝ dane są transferowane on-line to Uprawniony Podmiot ma moŝliwość uzyskania wszelkich danych poprzez analizę treści czy czasu rozpoczęcia czy zakończenia transferu danych poprzez interfejs HI3. 8. IV pkt W sieci TP tylko jeden z systemów (VoIP) koduje dane w systemie ASN.1, dla pozostałych systemów dane są pobierane ręcznie z systemów kolekcji naleŝy dopuścić za porozumieniem stosowanie formatu.txt, naleŝy uszczegółowić co to są dane skojarzone jeśli chodzi o dostęp do Internetu. 9. IV pkt 4.1 zapis jest niejednoznaczny. Czy dotyczy całości treści sesji,czy pojedynczych ramek (w przypadku usług dostępu do internetu) czego przekazu? 10. V pkt 1.3 dopisać IPv6 systemy SłuŜb muszą być gotowe na IPv V pkt 1.6 dopuścić format.txt. ASN1 nie jest stosowany poza jednym systemem w TP, przebudowa systemów byłaby kosztowna.. 3

14 Warszawa, dnia 24 maja 2011 r. Uwagi Polkomtel S.A. do projektu rozporządzenia Rady Ministrów w sprawie wymagać technicznych i eksploatacyjnych dla interfejsów umożliwiających wykonywanie zadań i obowiązków na rzecz obronności, bezpieczeństwa oraz bezpieczeństwa i porządku publicznego (projekt z dnia 13 maja 2011 r.) I. Uwagi do treści projektu rozporządzenia: 1. Z uwagi na skalę proponowanych zmian, oraz istotność regulowanej materii, wskazane jest aby przedmiotowe rozporządzenie zapewniało trwałości obecnie funkcjonujących rozwiązań. W projekcie rozporządzenia powinien znaleźć się zapis zwalniający operatorów którzy już posiadają zawarte porozumienia z podmiotami uprawnionymi na udostępnianie treści przekazów telekomunikacyjnych za pośrednictwem interfejsów z obowiązku posiadania rozwiązania zgodnego z proponowaną w nowelizacji specyfikacją. Brak zapisu o bezwarunkowym dopuszczeniu do dalszego użytkowania rozwiązań, które funkcjonują już teraz trudno odczytać inaczej, jak swego rodzaju sankcję nałożoną na tych operatorów, którzy wychodząc naprzeciw potrzebom Państwa zainwestowali olbrzymie środki (zarówno finansowe, jak i ludzkie) w wypracowanie, uzgodnienie a następnie zaimplementowanie interfejsu. Podkreślić trzeba, że konieczność dostosowania obecnie użytkowanych rozwiązań do proponowanego rozporządzenia będzie zmuszała operatorów do rozważenia czy ponosić dalsze koszty dostosowywania i utrzymywania interfejsu, czy też powrócić do sytuacji sprzed kilku lat, kiedy nie było interfejsów. Nie ulega wątpliwości, że w przypadku wyłączenia interfejsów najbardziej zmianę tę odczują podmioty uprawnione, które inwestowały olbrzymie publiczne środki w budowę systemów, które teraz trzeba będzie albo zmienić, albo wręcz w niektórych obszarach wyłączyć. Warto też zauważyć, że w przypadku gdy operator jednak zdecyduje się na dostosowanie systemu do nowych wymagań, to i tak przez okres kilku miesięcy (czas na przebudowę i ponowną certyfikacji systemu) podmioty uprawnione, które już teraz mają podpisane stosowne porozumienia, zostaną pozbawione możliwości korzystania z interfejsu. Aby uniknąć wyżej opisanych problemów wystarczy zapisać w rozporządzeniu, że specyfikacja dotyczy wyłącznie interfejsu do tych podmiotów, które w chwili wejścia w życie rozporządzenia nie miały podpisanego porozumienia o którym mowa w art. 179 ust 4a. 2. Polkomtel pragnie również zwrócić uwagę na konieczność zachowania odpowiedniego vacatio legis umożliwiającego operatorom implementację proponowanych zmian. Przewidziany w projekcie termin wejścia w życie rozporządzania po upływie 6 miesięcy o dnia ogłoszenia powinien zostać znacznie wydłużony. Istotnym jest, iż harmonogramy budżetowania środków u największych operatorów nie umożliwiają dokonania istotnych 1

15 zmian w nagłym trybie. Ponadto, należy wskazać, iż niezbędne jest zachowanie odpowiedniego czasu dla operatorów na opracowanie i wdrożenie zmian przewidzianych w projekcie rozporządzenia. Dodatkowo należy wskazać, iż zaimplementowane nowe rozwiązanie winno przejść proces certyfikacji dokonywanej przez Agencję Bezpieczeństwa Wewnętrznego, który to proces trwa wiele miesięcy. Mając na uwadze powyższe Polkomtel stoi na stanowisku, iż wejście w życie rozporządzenia winno nastąpić z zachowaniem co najmniej 36-miesięcznego vacatio legis. Krótszy okres na dostosowanie do nowej sytuacji prawnej będzie dodatkowym argumentem dla operatorów za tym, aby nie ponosić ryzyka braku zgodności posiadanych rozwiązań z przepisami, tylko wyłączyć możliwość korzystania z interfejsu. Podkreślenia wymaga, iż zgodnie z delegacją ustawową zawartą w art. 182 ustawy Prawo telekomunikacyjne projekt rozporządzenia winien być opracowywany z zachowaniem zasady minimalizacji nakładów przedsiębiorcy telekomunikacyjnego i podmiotów uprawnionych. 3. Istnieje uzasadniona obawa czy opisany w załącznikach interfejs jest możliwy do zaimplementowania oraz czy będzie funkcjonował w sposób prawidłowy. Obawa wynika z faktu, iż w projekcie rozporządzenia znajduje się szereg istotnych błędów (wskazanych poniżej). Nie bez znaczenie jest fakt, iż na etapie tworzenia specyfikacji pominięto etap konsultacji z operatorami, którzy bez wątpienia dysponują zarówno wiedzą teoretyczną, ale również praktyczną (w zakresie projektowania, wdrażania i bieżącej obsługi interfejsów). II. Uwagi szczegółowe do treści załączników do projektu rozporządzenia: 1. Załącznik 1 wymagania techniczne i eksploatacyjne a. Rozdział III (określenia użyte w załącznikach oznaczają): i. W definicji w pkt 3 (obiekt monitorowany) należy usunąć słowa użytkownik lub abonent b. Rozdział IV (Interfejs LI HI) i. pkt 1.1 zamiast 1000BASE-T zapisać 100/1000BASE-T ii. pkt 1.2 zamiast wymagane zapisać zalecane iii. pkt 1.3 należy doprecyzować o jaki protokół chodzi iv. pkt 1.6 proponujemy nowe brzmienie całego punktu, zgodne z obowiązującą specyfikacją LIHI na której wzorował się ustawodawca: LIID dla danego typu obiektu (MSISDN, IMEI itp.) zawiera tylko jedna usługę do monitorowania (jedna usługa per LIID). Jeśli obiekt będzie wymagał monitorowania kilku usług, system LEMF powinien za każdym razem przydzielić nowe LIID. Z punktu widzenia użytkownika systemu LEMF nie powinno to przysparzać problemów z gromadzeniem treści różnych usług dla jednego monitorowanego obiektu v. pkt 2.3 i 2.4 zamiast obu punktów proponujemy umieszczenie tabeli (macierzy) pokazującej jakie kryteria obserwacji (parametry) mogą wystąpić w każdej z usług vi. pkt 2.4, lit. c - zamiast dostęp do internetu powinno być zapisane usługi dostępu do internetu np.: wlan, dsl vii. pkt 2.4, lit. d - brak w 2.3 kryteriów monitorowania dla IMSa viii. pkt 2.6 punkt wewnętrznie sprzeczny skutkujący brakiem możliwości implementacji rozporządzenia w systemie operatora ix. pkt 2.9 brak technicznych możliwości realizacji takiego wymagania w systemie operatora. Dodatkowo zapis wykracza poza obowiązki określone w ustawie prawo telekomunikacyjne 2

16 x. pkt 2.10 brak technicznej możliwości realizacji takiego wymagania w systemie operatora. Dodatkowo zapis wykracza poza obowiązki określone w ustawie prawo telekomunikacyjne xi. pkt 2.12 zapis w obecnym kształcie stanowi bardzo poważne zagrożenie bezpieczeństwa, w tym związane z ujawnieniem celu (obiektu monitorowanego) należy usunąć słowa włączenia/wyłączenia trybu online oraz xii. pkt 3.2 wskazany standard ETSI dotyczy tylko usług mobilnych; należy sprawdzić, czy faktycznie wyłącznie dla usług mobilnych ma być realizowane to wymaganie xiii. pkt 3.4 należy określić jakie są dopuszczalne wartości pola z nazwą rozszerzenia - ext xiv. pkt 4.3 podział na online i offline ma tylko zastosowanie dla usług rozmów głosowych w sieciach mobilnych c. Rozdział V (interfejs HI A-B) i. pkt 1.3 zamiast LI HI powinno być HI A-B 2. Załącznik 2 specyfikacja elementów interfejsu HI1 i. pkt należy usunąć zapis dot. RTRequest ii. pkt należy usunąć Dopuszcza się wysłanie zlecenia aktywacji z pewnym wyprzedzeniem, gdyż taki zapis jest sprzeczny z punktem 2.6 iii. pkt zapis jest sprzeczny z punktem 2.8 iv. pkt brak zdefiniowanych wymaganych minimalnych parametrów kryptograficznych długości klucza, algorytmy v. załączone struktury ASN.1 są niepoprawne i nie kompilują się np. UnsignedRequestDetail (specyfikacja ASN.1 dla UnsignedRequestDetail) skutkuje to brakiem możliwości implementacji w systemie operatora, co z kolei będzie skutkować koniecznością wyłączenia interfejsu i powrotu do bezinterfejsowego obsługiwania wniosków podmiotów uprawnionych vi. W strukturach ASN.1 usunięto komentarze, które są niezbędne do właściwego i jednoznacznego zaimplementowania w systemie operatora wymagań określonych w rozporządzeniu vii. Brak określonego sposobu kodowania dla parametrów takich jak MSISDN, IMSI np. w UsnignedRequestDetail, strona 15 viii. Umieszczony w strukturze ASN.1 Regon (strona 22) powinien być opcjonalny 3

17

18

19

20

21

22

23

24 Polska Telefonia Cyfrowa Sp. z 0.0. Warszawa.dn. 26 maja r. DG-1700/BSR/496/2011 Pan Jacek osik Dyrektor Departamentu Spraw Obronnych Ministerstwo Infrastruktury Komunikacji Elektronicznej Ul. Cha³biñskiego 4/ Warszawa W nawi¹zaniu do pisma Ministerstwa z dnia 27 kwietnia 2011 r.. znak: MO-4jl-020-4(14) /10 dotycz¹cego projektu rozporz¹dzenia Rady Ministrów w sprawie wymagañ technicznych i eksploatacyjnych dla interfejsów umo liwiaj¹cych wykonanie zadañ i obowi¹zków na rzecz obronnoœci. bezpieczeñstwa pañstwa oraz bezpieczeñstwa i porz¹dku publicznego. stanowi¹cego wykonanie upowa nienia ustawowego zawartego wart. 182 ustawy z dnia 16 lipca 2004 r. - Prawo telekomunikacyjne PTCuprzejmie przedstawia wymagane informacje w wersji papierowej (za³¹cznik 1) oraz w formie elektronicznej stanowi¹cej za³¹cznik 2 do niniejszego pisma. 1. Uwagido rozporz¹dzenia: a) Prosimyzaktualizowaædatê rozporz¹dzenia i zmieniærok 2010 na rok b) W rozporz¹dzeniu powinien znaleÿæsiê zapis, e z obowi¹zku posiadania rozwi¹zania zgodnego z proponowan¹ specyfikacj¹ zwolnieni s¹ wszyscy operatorzy. którzy ju posiadaj¹ zawarte porozumienia z podmiotami uprawnionymi na udostêpnianie treœci przekazów telekomunikacyjnychza poœrednictweminterfejsów. PolskaTelefoniaCyfrowaSp.z 0.0.,Siedziba:Al.Jerozolimskie Warszawa. tel. +48 (O) , zarejestrowana w S¹dzie Rejonowym dla m.st. Warszawy w XIX Wydziale Gospodarczym Krajowego Rejestru S¹dowego, pod numerem KRS29159 NIP , REGON , Kapita³ Zak³adowy 471 mln z³otych, Konto Bankowe - BREBank S.A. OR/Warszawa.Nr ,

25 c) Wejœcie w ycie rozporz¹dzenia powinno nast¹piæ po 36 miesi¹cach. Wynika to z harmonogramów bud etowania œrodków w spó³kach operatorów, czasu niezbêdnego na opracowanie i wdro enie zmian oraz wielomiesiêcznegoprocesu certyfikacji rozwi¹zania przez ABW. 2. Uwagido za³¹czników: a) Generalna uwaga dotyczy obawy, czy opisy w za³¹cznikach pozwol¹ na implementacjê i prawid³owe dzia³anie przedmiotowych interfejsów. Obawa wynika z faktu, e w rozporz¹dzeniu znajduj¹ siê szereg powa nych niezgodnoœci,a na etapie tworzenia specyfikacji w ca³oœci pominiêto etap konsultacji z operatorami, którzy bez w¹tpienia dysponuj¹ zarówno wiedz¹ teoretyczn¹ jak i doœwiadczeniempraktycznym (w zakresie projektowania, wdra ania i bie ¹cej obs³ugi interfejsów) b) Uwagiszczegó³owedo za³¹czników: Za³¹cznik 1 - wymagania techniczne i eksploatacyjne Rozdzia³III(okreœleniau yte w za³¹cznikach oznaczaj¹): W definicji w pkt 3 (obiekt monitorowany) nale y usun¹æ s³owa "u ytkowniklub abonent" Rozdzia³IV(Interfejs U HI) pkt 1.1- zamiast" 1OOOBAsE-T" zapisaæ" 100/1 000 BASE-T". pkt zamiast "wymagane" zapisaæ"zalecane". pkt nale y doprecyzowaæ,o ja ki protokó³ chodzi. pkt proponujemynowe brzmienieca³ego punktu, zgodne z obowi¹zuj¹c¹ specyfikacj¹ UHI,na którejwzorowa³siê ustawodawca: "LIIO dla danego typu obiektu (MSISON, IMEI itp.] zawiera tylko jedna us³ugê do monitorowania Uedna us³ugaper LIIO).Jeœliobiekt bêdzie wymaga³ monitorowania kilku us³ug, system LEMFpowinien za ka dym razem przydzieliænowe LIIO.Zpunktu widzenia u ytkownika systemu LEMFnie powinno to przysparzaæproblemów z gromadzeniem treœciró nych us³ug dla jednego monitorowanego obiektu." 2

26 pkt 2.3 i zamiast obu punktów proponujemy umieszczenie tabeli (macierzy) pokazuj¹cej jakie kryteria obserwacji (parametry) mog¹ wyst¹piæw ka dej z us³ug. pkt 2.4, lit. c - zamiast "dostêp do internetu" powinno byæ zapisane "us³ugi dostêpu do internetu np.: wian, dsl". pkt 2.4, lit. d - brak w 2.3 kryteriów monitorowania dla IMSa. pkt punkt wewnêtrznie sprzeczny skutkuj¹cy brakiem mo liwoœci implementacji rozporz¹dzenia w systemie operatora. pkt brak technicznych mo liwoœcirealizacji takiego wymagania w systemie operatora. Dodatkowozapis wykracza poza obowi¹zki okreœlonew ustawie prawo telekomunikacyjne. pkt brak technicznej mo liwoœcirealizacji takiego wymagania w systemie operatora. Dodatkowozapis wykracza poza obowi¹zki okreœlonew ustawie prawo telekomunikacyjne. pkt zapis w obecnym kszta³cie stanowi bardzo powa ne zagro enie bezpieczeñstwa, w tym zwi¹zane z ujawnieniem celu (obiektu monitorowanego) - nale y usun¹æ s³owa "w³¹czenia/wy³¹czenia trybu online oraz". pkt wskazany standard ETSIdotyczy tylko us³ug mobilnych; nale y sprawdziæ, czy faktycznie to wymaganie ma byærealizowane wy³¹cznie dla us³ug mobilnych. pkt nale y okreœliæ, jakie s¹ dopuszczalne wartoœcipola z nazw¹ rozszerzenia- ext. pkt podzia³ na online i offline ma tylko zastosowania dla us³ug g³osowych w sieciach mobilnych. pkt wskazana norma nie dotyczy ULIC. Rozdzia³V(interfejs HI A-B): pkt 1.3- zamiast "LIHI"powinno byæ"hia-b". Za³¹cznik 2 - specyfikacja elementów interfejsu HI1. pkt nale y usun¹æ zapis dot. RTRequest. pkt nale y usun¹æ "Dopuszcza siê wys³anie zlecenia aktywacji z pewnym wyprzedzeniem",gdy taki zapis jest sprzeczny z punktem 2.6. pkt zapis jest sprzecznyz punktem 2.8. pkt brak zdefiniowanych wymaganych minimalnych parametrów kryptograficznych - d³ugoœciklucza,algorytmy. za³¹czone struktury ASN.l s¹ niepoprawne i nie kompiluj¹ siê - np. UnsignedRequestDetail (specyfikacja ASN.l dla UnsignedRequestDetail) - skutkuje to brakiem mo liwoœci 3

27 implementacjiw systemieoperatora, co z kolei bêdzie skutkowaækoniecznoœci¹wy³¹czenia interfejsu i powrotu do "bezinterfejsowego"obs³ugiwania wnioskówpodmiotów uprawnionych. W strukturach ASN.1usuniêto komentarze, które s¹ niezbêdne do w³aœciwegoi jednoznacznego zaimplementowania w systemie operatora wymagañ okreœlonychw rozporz¹dzeniu. Brak okreœlonegosposobu kodowania dla parametrów takich jak MSISDN,IMSI np. w UsnignedRequestDetail,strona 15. Umieszczonyw strukturze ASN.1Regon (strona 22) powinien byæopcjonalny. Podsumowuj¹c PTCwidzi powa ne zagro enie, dla mo liwoœcimplementacji przedmiotowych obowi¹zków w oparciu o rozporz¹dzenie o opublikowanej treœci.st¹d prosimy uprzejmie o uwzglêdnienie powy szych uwag w idealnym przypadku po przeprowadzeniu konsultacji ze œrodowiskiem. W przekonaniu PTC takie postêpowanie zagwarantuje dopracowanie rozporz¹dzenia do poziomu jego akceptowalnoœci.na chwilê obecn¹ projekt rozporz¹dzenia tego poziomu nie osi¹ga. Za PTC Cezary Albrecht C /ff0ic},} Dy~ektor Biura Spraw Regulacyjnych 4