Wyniki 1-4 spośród 4 dla zapytania: authorDesc:"Piotr Pyda"

LEKKI OCSP DLA SIECI WYDZIELONYCH O NISKICH ZASOBACH DOI:10.15199/59.2019.7.26


  1. WSTĘP Standard X.509 wyróżnia zaufaną trzecią stronę, która wydając użytkownikowi certyfikat potwierdza jego wiarygodność. Certyfikat zawiera m.in. informacje na temat wydawcy, podmiotu go otrzymującego, jego ważność oraz potwierdzenie za pomocą podpisu cyfrowego o ścisłym związku pomiędzy podmiotem a kluczem, jaki jest przez niego używany. Zdarzają się sytuacje, że z jakiegoś powodu certyfikat jest unieważniany lub aktualizowany. Urząd Certyfikacji (ang. CA - Certification Authority), który wydaje certyfikaty, utrzymuje w bazach danych i repozytoriach dane na temat ich stanu. Powszechnie istnieją dwa sposoby sprawdzenia stanu certyfikatu: za pomocą listy CRL (ang. Certificate Revocation List) oraz z wykorzystaniem protokołu OCSP (ang. Online Certificate Status Protocol). Pierwszy z nich polega na analizowaniu listy odwołanych certyfikatów przesłanej z serwera CA, natomiast drugi wykorzystuje protokół wysyłający do serwera zapytanie o konkretny certyfikat i w odpowiedzi otrzymuje aktualny jego status. Główne zalety OCSP to: aktualność odpowiedzi oraz stały rozmiar żądania i odpowiedzi, otrzymywanie informacji w czasie rzeczywistym tylko o interesującym certyfikacie. To też jest wymieniane jako wada, gdyż na serwerze CA znajdują się informacje, które certyfikaty klient próbował zweryfikować. Natomiast istotną wadą list CRL jest konieczność przeszukiwania całej listy, która może być długa i nieaktualna, gdyż np. była otrzymana tydzień wcześniej. Artykuł przedstawia propozycję lekkiego protokołu OCSP, od którego wymaga się znacznie mniejszego zapotrzebowania na pasmo niż protokół w wersji standardowej. Stosowany byłby on w sieci wydzielonej o niskich zasobach, która nie jest dołączona do Internetu. Dodatkowo przepustowość tej sieci jest na tyle niska, że ruch generowany przez standardowy protokół OCSP mógłby degradować w niej jakość obsługi innych danych. Przykładem takiej sieci może być wojskowa sieć radiowa, w której[...]

USŁUGA TRANSLACJI NAZW DLA APLIKACJI W SIECI TAKTYCZNEJ ZORIENTOWANEJ NA USŁUGI - KONCEPCJA I REALIZACJA DOI:10.15199/59.2017.8-9.42


  System nazw domenowych (ang. Domain Name Service, DNS), to złożony system serwerów, protokołów komunikacyjnych oraz usługa, która umożliwia przekształcanie mnemonicznych (łatwych do przyswojenia przez człowieka) nazw urządzeń i usług dołączonych do Internetu na adresy wymagane przez urządzenia sieciowe. Podobne zastosowanie DNS ma miejsce w sieciach * Prezentowane wyniki uzyskane w ramach prac projektu TACTICS EDA B 0980 GP taktycznych IP, gdzie również bardziej praktyczne jest posługiwanie się nazwami niż adresami numerycznymi poszczególnych węzłów. Dostępnych jest wiele implementacji internetowej usługi translacji nazw - zarówno komercyjnych, jak i otwartych (ang. open source). Reprezentatywnymi przykładami są: oprogramowanie BIND (aktualnie w wersji 9), Microsoft DNS, CISCO Network Registrar, Unbound, NSD i wiele innych. Oprogramowanie to zapewnia funkcje zebrane w szeregu dokumentów RFC, mających na celu zapewnienie jednolitego interfejsu dla tej usługi i interoperacyjności między różnymi producentami oprogramowania DNS [6] i powiązane RFC. Zgodność ze specyfikacją IETF może być zarówno zaletą, jak i wadą: w przypadku sieci komercyjnych pozwala na dobór implementacji na podstawie wymagań funkcjonalnych, bez zbytniego przywiązania do producenta danego oprogramowania, a w kontekście sieci taktycznych oznacza mniejszą elastyczność w dostosowaniu danego oprogramowania do indywidualnych potrzeb tego środowiska. W ramach prowadzonego projektu TACTICS wymagania w stosunku do usługi translacji nazw odnosiły się do obsługi mobilności węzłów i wielokrotnego dowiązania do sieci (tzw. multi-homing) oraz dopasowania do architektury zorientowanej na usługi (ang. Service Oriented Architecture, SOA). Z tego też względu została zaproponowana nowa usługa translacji nazw - TACTICS Name Service (TNS), zdefiniowana jako komponent z interfejsem usługi, gotowym do wykorzystania przez pozostałe usługi funkcjonalne w ramach systemu TACTI[...]

SPOSÓB WSPÓŁPRACY SYSTEMU INSIGMA Z KRAJOWYM SYSTEMEM POWIADAMIANIA RATUNKOWEGO DOI:10.15199/59.2015.4.13


  W artykule opisano możliwość współpracy systemu INSIGMA z krajowym Systemem Powiadamiania Ratunkowego. INSIGMA 1) jest złożonym systemem informacyjnym do celów kompleksowej detekcji i identyfikacji zagrożeń oraz monitoringu i identyfikacji obiektów ruchomych. Obszary tematyczne zadań projektu pokrywają się w istotnym zakresie z dziedzinami Systemu Powiadamiania Ratunkowego, zatem współpraca obu systemów i współdzielenie przez nie informacji mogą znacząco poprawić bezpieczeństwo obywateli. 1. WSTĘP Bezpieczeństwo obywateli jest ważnym filarem nowoczesnego państwa i jednym z największych priorytetów UE; ma zarazem szeroki, wieloaspektowy wymiar - np. w sytuacjach kryzysowych silnie zależy od działania systemu ratownictwa. Funkcjonowanie tego systemu jest z kolei uwarunkowane obowiązującymi procedurami i skutecznością powiadamiania o zdarzeniach stanowiących zagrożenie dla zdrowia i życia ludzi. Obsługa zgłoszeń alarmowych w krajach UE - w tym kierowanych na numer 112 oraz przyjmowanych przez systemy E112 i eCall - jest uregulowana odpowiednimi dyrektywami, komunikatami i zaleceniami [1…4]. Ustawa o Systemie Powiadamiania Ratunkowego (SPR), obowiązująca od 1 stycznia 2014 r. [5], w sposób kompleksowy normuje zagadnienia z zakresu powiadamiania ratunkowego, opierając SPR na Centrach Powiadamiania Ratunkowego (CPR). Podstawowym zadaniem SPR jest obsługa zgłoszeń alarmowych kierowanych do numerów 112 i 9xx. CPR-y wykonujące zadania SPR współpracują z Policją, Państwową Strażą Pożarną (PSP), dysponentami zespołów Państwowego Ratownictwa Medycznego (PRM) oraz dodatkowo z innymi podmiotami, których zadaniem jest ochrona życia, zdrowia, bezpieczeństwa i porządku publicznego, mienia lub środowiska (np. staż gminna). 2. SYSTEM POWIADAMIANIA RATUNKOWEGO SPR jest częścią Krajowego Systemu Ratownictwa (medycznego - PRM; technicznego - PSP; porządkowego - Policja itd.). Schemat funkcjonalny SPR przedstawiono na rys. 1. Zadani[...]

SPRAWNOŚĆ OBSŁUGI ZGŁOSZEŃ W SYSTEMIE INSIGMA*) POPRZEZ INFRASTRUKTURĘ DOSTĘPOWĄ O OGRANICZONEJ PRZEPUSTOWOŚCI DOI:10.15199/59.2015.8-9.93


  W referacie zamieszczono wyniki testów Systemu Obsługi Zgłoszeń o Zdarzeniach i Zagrożeniach (SOZZ) w warunkach zmniejszonej przepustowości łącza dostępowego. Referat ten jest próbą odpowiedzi na pytania dotyczące sprawności przekazu informacji o zdarzeniach w środowisku ogólnie określanym jako zdegradowane. Uzyskane wyniki wskazują na możliwości realizacji obsługi zgłoszeń z pewnymi ograniczeniami. Jako zasadniczy protokół do przekazu informacji o zdarzeniach zastosowany jest standardowy protokół SIP. 1. WSTĘP Zadaniem Systemu Obsługi Zgłoszeń o Zdarzeniach i Zagrożeniach jest dostarczanie danych dla podsystemu analizy ruchu drogowego w systemie INSIGMA. Obsługa zgłoszeń rozumiana jest tu jako zespół czynności wykonywanych w celu przyjęcia, przetworzenia i udostępnienia informacji o zdarzeniach i zagrożeniach w ruchu drogowym, napływających do systemu. Zgłaszane zdarzenia mogą mieć wpływ na jakość obsługi ruchu drogowego w aglomeracjach miejskich ale przede wszystkim wykorzystywane są do uzyskiwania informacji i monitorowania obszarów nieobjętych zasięgiem sensorów systemu INSIGMA. System SOZZ zapewnia tę funkcjonalność poprzez wykorzystanie tzw. sensorów mobilnych, którymi są różnego typu terminale przenośne - np. PDA, smartfony i inne urządzenia wyposażone w aplikację umożliwiającą zgłaszanie zaobserwowanych zagrożeń, wypadków czy innych zdarzeń mających wpływ na bezpieczeństwo ruchu drogowego. Jednym z problemów, które należało rozwiązać było zapewnienie możliwie krótkiego czasu przekazywania informacji o zdarzeniach drogowych do systemu INSIGMA. Zagadnienie to jest m.in. jednym z elementów sprawnego działania wszelkiego rodzaju służb ratowniczych (np. funkcjonujących w ramach Krajowego Systemu Ratownictwa). Znane są nowe techniki powiadamiania o zdarzeniach w sposób automatyczny (np. system eCall [13]), mimo to często jedynym źródłem informacji okazuje się być człowiek wyposażony w terminal przenośny (np. telefo[...]

 Strona 1