MAC 주소는 L2에서 사용되며, Ethernet에서 많이 사용되지만 Bluetooth 등 다른 L2 프로토콜에서도 사용되므로 Ethernet에서만 사용된다고 하면 틀린다.
Flat 하다는 표현? Tree 구조가 아닌 계층 구조적이라는 표현
MAC 주소가 주민등록번호와 같다는 표현은 틀린 표현이다? 개인마다 고정이 아니고 NIC마다 고정되었다고 하는게 맞음
만약 수신한 MAC Address가 FF:FF:FF:FF:FF:FF일 경우 무조건 받아야 하는 신호로 생각함, query packet
프레임의 preamble은 송신자, 수신자의 클록을 동기화하기 위해 사용, type은 VPN처럼 패킷 안에 패킷을 넣는 경우나 ssh turnel같은 경우 데이터 페이로드 안에 어떤 패킷이 들어오는지 표시함
이더넷은 CSMA/CD 방식을 쓴다
이진 백오프란 충돌이 발생할 경우 기다리고, 충돌이 발생할때마다 기다리는 시간을 2배로 늘리는 것, CSMA/CD가 쓴다?
Layer4의 특징 : End system, Delay는 의미가 없는 시스템에서만 재전송을 요구함(TCP), 이 경우 Delay 부분에 대한 QoS가 보장되지 않는 상태, 즉 Best Effort Class
카카오톡과 같은 tcp를 사용하는 connectionless 서비스는 문자가 실제로 전송된 시간은 모르고 도착한 시간만을 안다. 문자의 도착 자체가 가장 중요하기 때문이다.
Layer4의 통신 품질은 Layer3와 밀접한 관계가 있음, OSI 7계층은 원래 다른 계층에 영향을 받지 않지만 기술적으로 연관성이 높기 때문
CBN을 공부해야 하는 이유? PBN 기반에서 CBN 형태의 서비스를 제공하는 경우가 있기 때문, 대표적으로 VoLTE
PBN에서 CBN을 서비스함에도 마치 실제 CBN처럼 QoS가 보장되는 것 처럼 보이는 이유는 PBN의 대역폭이 필요량에 비해 굉장히 크기 때문이다.
4G 이후부터 CBN이 PBN으로 대체되었으나 서비스는 CBN과 비슷한 형태로 유지되는중
4G 이상의 PBN에서는 자원 점유는 없지만 경로는 먼저 정한 후 작동한다 마치 CBN처럼
이게 CBN을 어느정도는 다뤄야 하는 이유
Signaling System 7? 이게 전화가 걸릴 때 단말간 경로를 확보하고 실제로 전화가 걸릴 경우 SS7에 대한 연결은 전부 종료, 이런 식으로 경로를 사전에 확보하는 것이 CBN 형식, 경로 확보 과정에서 자원 점유도 이루어지며 점유된 자원을 통해서는 다른 단말의 데이터가 전송되지 않음
이로 인해 전화는 Real Time Service가 가능, Delay가 있지만 매우 낮음
Delay는 노드간 통신에 소요되는 시간이 대부분(transmission time 또는 propagation time)
전화에는 SS7과 같은 별도의 signaling system이 있었음
5G, 6G에도 SS7과 비슷한게 동작중, CBN Like
Voice Service의 Delay Spec? 200ms 이내면 됨, 19세기 말에 정립됨됨
이거는 Legacy Service
위 시스템에서 Delay는 200ms이고, Loss의 경우 10의 -6승이다.
주로 Layer 3를 기준으로 다룸
이 수업에서는 Loss와 Delay를 다루고 이중에서도 Delay에 집중함, 이유는 Loss의 경우 관련 수학적 지식들이 아직 부족해서 이해하기 힘들기 때문
PBN의 핵심은 Routing, Router에서 이루어짐
Router -> 라우팅 알고리즘, 라우팅 테이블, 엔드포인트를 향한 패킷 포워딩, Default Route(목적지로 향하는 길을 못 찾았을 때)때
Store & Forwarding을 라우터의 특징이라고 할 수도 있다. 자원 공유로 인해 발생하는 특징
패킷들은 절대로 동시에 도착할 수 없다. queue theory
Default Route로의 Route가 지속될 경우 쓰레기 패킷이 쌓이게 되므로 ttl을 지정하여 일정 시간이 지난 후 패킷을 버림, 이게 QoS가 보장된다고 말하기 힘든 이유이다.
라우팅 알고리즘은 패킷이 도착한 순서에 따라, 라우팅 테이블에 패킷의 목적지가 있는지 확인한 후에 그 목적지로 패킷을 보낸다? 라우팅 테이블에는 MAC 주소와 도달 방식도 들어있음.
Router에 있는 포트들의 MAC Address는 Link ID라고 부른다.
Routing Table에 있는 IP들은 CIDR같은거로 저장해서 모든 IP가 아닌 IP 범위별 주소를 저장한다?
라우팅 테이블이 채워지는 속도나 IP의 목적지를 찾는 시간은 알 수 없다.
라우팅 테이블에서 목적지를 찾을 경우 L2 프로세싱, 즉 프레임을 만드는 과정을 진행한다.
L3 패킷의 크기는 20~65535 바이트 사이
만약 L3 패킷의 크기가 65536인데 L2가 고정 크기로 53바이트를 사용한다면? Fragmentation을 통해 여러개의 L2 패킷으로 나눈다. 그리고 오류 체크를 한다. 이 과정을 L2 프로세싱이라고 한다.
Store And Foward 방식을 사용하는 이유는, 일단 자원 공유를 위해 패킷들을 쌓아놓고(Store) 하나씩 패킷을 보내기(Forward) 때문
네트워크 엔지니어링에서는 패킷을 쌓아놓는걸 메모리, 버퍼라고 하기보다는 큐(Queue)라고 한다.
푸아송 분포, 마르코프 체인?
PBN에서의 Delay는 계산 불가능하다. 복잡도 Big O가 무한? 이거는 NP Hard라고도 한다, 컴퓨터로 계산이 아닌 시뮬레이션으로 근사값을 구할 수는 있다.
L4는 End station에만 있다는 말? 이거는 Delay 에 대해 다룰 때 의미가 있는 말
Layer4의 대표적인 프로토콜은 TCP, UDP가 있다. UDP는 Error correction같은걸 할 여유가 없는 상황에 사용, TCP는 전송 소요 시간에 상관 없이 데이터의 신뢰성을 우선시하는 경우 사용
데이터를 가장 안전하게 보내는 방식은 CBN, Connection Oriented 방식으로 자원 공유 없이 보내는 것
TCP는 Connection Oriented 방식을 사용하듯이 동작한다. (가상의 전송 경로를 점유하는 방식 사용, 가상 회선 연결 방식), 3 way handshake는 언급만
UDP의 경우는 포트 번호만 보냄, 인터넷 통신 설계시간에 배움
라우터 – L3
스위치 – L2
허브 – L1
연결지향
오류제어, 흐름제어, 혼잡제어
높은 신뢰성, 순서 보장됨
http, ftp
비연결성
간단한 체크섬
낮은 신뢰성, 순서 보장 안됨
실시간 소통, 영상통화 등
연결 지향이란? 먼저 상대와 연결 통로를 만든 후 통신을 하는 것, TCP에서는 3 way handshake를 사용함
오류제어는 흐름제어에 포함되어 있음
흐름제어와 혼잡제어?
흐름 제어는 송신 측과 수신 측이 있다면 수신 측의 버퍼에서 나가는 속도보다 들어오는 속도를 빠르지 않게 해서 데이터가 DROP되지 않도록 하는 것을 흐름 제어라고 한다.
simplist protocol은 udp와 비슷하게 오류가 없다고 가정하고 일단 보냄
stop and wait은 일단 보내고 ack를 받아 오류를 감지함, ack를 받아야 다음걸 보냄, 윈도우는 1칸
go back N의 경우 stop and wait와 비슷하지만 윈도우 크기가 여러개, ack 넘버는 0부터 윈도우의 크기까지? 만약 ack가 5라면 5 이전까지 잘 도착했다는 뜻
만약 윈도우 size가 5인데 1~5중 2에서만 오류가 왔을 경우 2를 보내서 2~5를 전부 다시 요청한다
seletive repeat은 go back N과 다르게 받는 쪽의 윈도우를 늘려서 모든 패킷에 대해 ACK를 보내서 빠진 부분만 보낼 수 있도록 한다.
Bidirectional Protocol은 수신 측과 송신이 언제든 관계가 바뀔 수 있음, 시험에 piggybacking이 나옴, 이게 뭔지 알아보자
piggybacking은 양방향 통신을 할 때 ACK를 따로 보내는게 아니라, 보낼 데이터에 같이 실어서 보냄
혼잡 제어는 인터넷 전반에 걸친 것. 여러 사람들이 인터넷에 동시에 많은 부하를 걸 경우 인터넷 사용 자체가 불가능해지기 때문에 이를 막기 위해 혼잡 제어를 한다. 하지만 UDP의 경우 이를 무시한다.
CBN PBN은 네트워크가 어떤 식으로 전달되는가를 기준으로 나눈다
전화 통화는 Real Time, 그 외의 실시간성이 중요하지 않은건 Non Real Time(인터넷 등)
인터넷 등 PBN을 사용해서 QoS가 보장되지 않는 서비스를 Best Effort Service라고 한다.
4G 후반까지는 CBN, 5G부터는 PBN을 사용한다. 5G에서 Real Time을 보장하는 방법은?
PBN은 IP 주소만 가지고 있다면 그 목적지까지 도달하는 것을 철칙으로 한다.
형태라는 의미
Bus Type과 Star Type 등이 대표적이다.
L2 네트워크와 L3 네트워크, (L3는 안 붙이는 경우도 있음)
Hop to Hop만 있으면 L2 네트워크
Bus Type은 모든 노드가 Hop to Hop 구성이기 때문에 L2 네트워크에 해당한다.
LAN MAN WAN 순으로 규모가 큰 네트워크.
LAN은 캠퍼스 사이즈
MAN은 도시 사이즈
WAN은 국가 사이즈
Bus Type 네트워크 두개가 서로 연결된 상태는 L3 네트워크라고 하며 Bus Type 네트워크들을 이어주는 네트워크 장비는 L3
두 네트워크를 L2 장비로 이을 경우에는 두 네트워크가 이어져도 L2 네트워크?
4G 후반부터 CBN과 PBN을 합친 Broadband convergence Network가 사용된다.
Circuit Based Network, Packet Based Network로 나눠짐
Circuit Based Network -> 회선 기반 망
Packet Based Network -> 패킷 기반 망
과거 전화 교환원이 있던 시절 교환원이 신호를 연결하는 과정을 signaling이라고 한다. 통신 시작 직전까지의 모든 신호를 의미
Circuit은 데이터가 지나가는 경로, 즉 Data Path(요즘에는 Routing Path)
signaling은 자원 점유라고도 한다.
Connection Oriented Service, 연결 지향형 서비스
데이터를 보내는 Data Path가 생성되기 전 signaling을 통해 두 개체의 연결을 확인한 후 데이터의 송신이 이루어지게 하는 형태라고 한다.
CBN은 QoS가 보장된다.
Packet Based Network
Signaling이 없다, Connectionless Service(정해진 connection이 없다는 의미)
자원을 공유한다.
QoS 보장은 불가능하다.
인터넷이 PBN에 해당한다.
최근 추세는 CBN+PBN 형태로 운용하는 것
각 클라우드 스토리지 서비스 제공자별로 사용자의 활동이 어느정도 수준으로 어떤 부분이 기록되는지를 파악함
Box 클라우드 스토리지 서비스에서는 서비스 내부적으로 어떤 툴을 사용하였는지도 기록함
내부 API 트래픽을 분석하여 파일 활동 로그 기반 10가지 주요 사용자 행위 식별 방법론 제안
각 서비스 제공자별 공통 필드가 무엇이며, 각 서비스별 특징적인 필드가 무엇인지를 확보
비공개 API를 대상으로 진행한 연구이기 때문에 API 구조 변경 가능성 있음, 법적 근거로 사용되기 위해서는 제대로 된 법적 절차를 밟아야 함
macos용 카카오톡 데이터베이스 복호화 방안 연구의 후속 연구
MacOS용 카카오톡 바이너리는 ARM, X86이 섞여있는 형태였음
카카오톡 데이터베이스 파일명, 데이터베이스 키 생성은 Device UUID와 SHA를 사용하여 생성됨
유저, 단체채팅 디렉터리 이름은 이름을 역순으로 뒤집는 등의 난독화?를 거쳐 생성됨
위 키 생성 원리를 역순으로 진행하면 카카오톡 채팅방에 있던 이미지 등을 복호화 하는게 가능함
코드 수준의 오류는 로봇 동작으로 반영됨
LLM 수준의 오류도 동작으로 반영, 즉 현실로 이어짐
LLM 생성 제어 코드를 ROS2 환경에서 실제 실행해봄
생성한 코드를 별도의 수정 없이 즉시 ROS2 환경에 적용한 것이 핵심
validator 기반 mitigation 기법, LLM이 생성한 코드를 validator를 통해 안정성 검사 수행, 규칙 기반으로 동작함
4개의 주요 목표, 20개의 환경으로 총 80개의 시나리오를 사용
Failure는 충돌, 비정상 동작, 목표 미도달, 실행 실패로 정의함
코드의 구조적 문제로 인한 실행 실패는 개선하지 못한 것을 알 수 있음
과도한 전진, 공격적인 이동이 줄어들어 더 안정적인 제어가 이루어진 결과로 해석이 가능함
굳이 LLM 코드를 바로 로봇에 적용시킬 때 저런 위험 요소를 줄인다기 보다는 QA 자체를 더 강화하는게 결과적으로는 더 효율적이지 않을까?
validator 기반 mitigation 기법에서 어떻게 위험한 코드를 인식하는지?
규칙기반, 정적 분석 기반, LLM 기반
정적 분석 기반은 빠른 처리가 장점
LLM 기반의 경우 C2SafeRust가 있음
정적 분석 기반으로 변환된 코드를 LLM이 실행을 통해 원본 코드와 동일하게 작동하는지를 검증한다.
Sactor 또한 LLM 기반, C 코드를 보존하는 비 Rust 코드로 변환, 이후 Crown 분석 후 LLM으로 Rust로 변환함
Deepseek R1이 가장 좋은 결과를 냄
한계 : 외부 C 라이브러리 의존성, 복잡한 데이터 구조, 형식적 정확성 보장 부재
컴파일 통과 후 종단간 암호화 테스트?를 거쳐도 모든 경우에 원본과 동일한 동작을 한다고 보장할 수 없음
기존 안전 정책만으로는 LLM을 대상으로 하는 공격을 막기 힘듦
모델이 어떤 지시를 신뢰하고 따라야 하는지에 대한 문제이다.
실제 서비스 환경에서는 여러가지 tool과 결합되어 나타날 수 있음
LLM 보안은 프롬프트 문제가 아닌 LLM과 연관된 시스템 전반에 대한 문제
LLM 공격에 대한 위협으로는 프롬프트 인젝션, 탈옥 등이 있음
프롬프트 인젝션 : 시스템 프롬프트나 외부 입력에 악의적인 내용을 추가하여 원래 기능과 다른 기능을 하게 하는 것, RAG이나 에이전틱 환경에서 더 위험성이 커진다.
Direct 프롬프트 인젝션은 사용자가 직접, Indirect는 웹페이지 등에 악의적인 프롬프트를 숨기는 것, RAG을 대상으로?
실제 서비스에서는 Indirect Prompt injection이 더 위험할 수 있음
Jailbreak는 학습, 정렬 과정에서 갖게 된 안정 정책을 우회하는 것을 목적으로 함. 이전까지는 사용자가 직접 Jailbreak prompt를 작성하는 형태였지만 현재는 멀티턴, 자동 최적화, 이미지 기반 공격 등 여러가지 공격 수법이 사용되고 있음.
최근 공격은 사용자가 직접 프롬프트를 작성하는 것이 아닌 에이전트, 자동화를 적극적으로 사용하는 추세
멀티턴 에이전트 환경을 고려하여 단순한 프롬프트 방어가 아닌 LLM 시스템 전반에 대한 방어가 중요해짐
기존 보안 모델로는 Agentic AI에 충분한 수준의 보안을 제공할 수 없음
공통적인 취약점으로 내부 구성 요소를 신뢰한다는 것이 있음, 이를 해결하기 위해 제로 트러스트를 도입할 수 있다.
제로 트러스트의 필요성? 내부 에이전트에 대한 지속적인 검증이 필요, 내부 에이전트가 공격자에게 탈취당하거나, 오염된 경우 신뢰하지 않아야 함
에이전트가 작동 과정에서 생성한 코드가 안전한지를 검사해야 함
필요성 : LLM은 제 3자 운용 과정에서 원본 LLM에 추가 파인튜닝, 압축, 교체, 백도어 삽입 등의 변조가 발생할 수 있음
prefix tuning이란 대규모 언어모델의 모든 파라미터를 고정한 후 입력 앞에 학습가능한 prefix embedding을 추가하여 모델의 동작을 조정하는 기법
모델 가중치에 직접적으로 접근이 불가능한 상태에서 유용하다?
이 발표는 방어가 아닌 공격 관점, AI 모델이 피싱 사이트에서 로고가 일반적인 회사의 로고와 비슷하다고 판단할 경우 피싱 사이트로 분류하는데 사람의 입장에서는 충분히 원본 로고와 유사하게 보이지만 AI 입장에서는 피싱 사이트라고 분류하지 않을 수준으로 다르게 보이는 로고를 생성하는 방법을 제시함
과도한 정보 노출로, 민감하지 않은 정보들이 민감 정보로 합성될 가능성이 있음, 필요한 필드만을 출력함으로써 이와 같은 문제를 예방한다.
Atomic Read를 통해 최소 단위 데이터를 반환한다.
하지만 대부분의 MCP의 경우 재사용성과 개발 편의성을 위해 정보의 최소화 원칙을 지키지 못하고 있다. 단 한번의 도구 호출만으로 민감한 정보 노출이 가능.
현실적으로 Atomic Read로 전부 전환하는건 불가능함, 관리 복잡도 증가, 도구 선택 오류 가능성, 레거시 지원 등의 문제가 있음
기존의 데이터 유출 방지 솔루션의 범위를 MCP 도구 호출에서도 적용해야 한다. 단순 키워드 필터링이 아닌 MCP가 사용자의 프롬프트를 이해하는 수준
제어 이론 : 동역학계에서 시스템을 원하는 방향으로 작동하는 것
단일 에이전트에서는 입력, 권한 경계를 보호
다중 에이전트에서는 관계, 전파, 거버넌스 보호가 중요함
같은 공격 형식이더라도 단일 에이전트보다 다중 에이전트에서 더 큰 피해가 발생한다. 피해가 로컬에서 네트워크 전체로 전파됨
ACE(NDSS 2026)