Kedves Péter, Bocsánat a lassú válaszért! Igen, július 17 lesz célszerű. Addig haladunk a milestone riporttal is. Köszönettel: Levente On 03/07/2025 07:44, Peter 1. Szilagyi (Nokia) wrote:
Sziasztok!
Köszönöm az összefoglalót. Ezek szerint július 17-én találkozunk a megszokott időben?
Üdv, Péter
-----Original Message----- From: Levente Buttyán <buttyan@crysys.hu> Sent: 2 July, 2025 21:52 To: 5gsecurity@crysys.hu Cc: Peter 1. Szilagyi (Nokia) <peter.1.szilagyi@nokia-bell-labs.com> Subject: Holnapi Nokia-CrySyS meeting
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
Sziasztok!
Holnap úgy néz ki elég sokan szabin leszünk (én és Biczók Gergpő biztosan), ezért ha lehet a meetingünket kihagyhatnánk holnap.
Elnézést a short notice-ért!
Azért haladtunk a munkával a legutóbbi meeting óta, Dóri összefoglalóját a munkáról küldöm alább:
A megbeszélésen odáig jutottunk, hogy ha a rendszerben előforduló szolgáltatások mindegyike csak egy másik szolgáltatástól függ, akkor hogyan számítható a hibaterjedés a rendszeren. Azóta azon dolgozunk, hogy ezt a hibaterjedési modell kiterjesszük arra az esetre, amikor egy-egy szolgáltatásnak több dependenciája is van és a dependenciák hibaállapotait aggregálnunk kell. Több lehetséges stratégiát is megvizsgáltunk. A naiv megoldás az lenne, ha a dependenciák minden lehetséges hibaállapot-kombinációját szimulálva kimérjük az eredő hibaállapotot. Ez nagyon pontos hibamodellt adna, viszont a sok mérés miatt elég rosszul skálázódik.
Ehelyett inkább arra gondoltunk, hogy a dependenciák hibaállapotait, mint halmazt nézzük és ebből a halmazból választanánk a legrosszabb hibaállapotot, mint a továbbterjedő hibaállapot, vagyis worst-case-t számolnánk. Sajnos a hibaállapotok halmaza nem teljesen rendezhető, mert előfordulnak hibaállapotok, amelyek összehasonlításkor egyik dimenzióban jobbak, másikban rosszabbak. Pl. a "korrekt, de későn érkező válasz" hibáját kell összehasonlítanunk a "időben érkező, de hibás válasz" hibájával. Ezek között nem lehet általánosan, minden rendszerre igaz módon megmondani, hogy melyik rosszabb, mert ez az adott rendszer követelményeitől függ.
Ezért azt javasoljuk, hogy az impact analízist egy-egy system capability-re (integrity, availability, ...) koncentrálva végezzük el. Az integrity fókuszú elemzéskor csak a helyes-helytelen válasz dimenzióban mozogva teljesen rendezhető a hibaállapotok halmaza: a helytelen válasz mindig rosszabb, mint a helyes. Availability-re fókuszálva is teljesen rendezhető a hibaállapotok halmaza: a normál időzítéssel érkező válasznál rosszabb a késve érkező válasz (delay: increased), aminél még rosszabb, ha néha időtúllépés miatt nem érkezik válasz (responsiveness: sometimes), de a legrosszabb, ha sose érkezik válasz időkorláton belül (responsiveness: never).
Ennek a megközelítésnek nagy előnye, hogy csak páronként kell a hibaállapotok mérését elvégezni, az összesítést és elemzést plusz mérések nélkül el lehet végezni, vagyis remélhetőleg jól skálázódik. A hátránya viszont, hogy nem vesz figyelembe olyan eseteket, amikor a hibadimenziók hatnak egymásra, pl. helytelen válaszokat küldő dependencia miatt egy-egy szolgáltatás lelassul vagy kiesik. Még gondolkozunk, hogyan lehetne ezeket az eseteket skálázhatóak kezelni.
Köszönettel: Levente
-- Prof. Levente Buttyán Laboratory of Cryptography and System Security (CrySyS Lab) Department of Networked Systems and Services Budapest University of Technology and Economics (BME) https://www.crysys.hu/
-- Prof. Levente Buttyán Laboratory of Cryptography and System Security (CrySyS Lab) Department of Networked Systems and Services Budapest University of Technology and Economics (BME) https://www.crysys.hu/