Q: In the 7 layer model, what are some security ‘opportunities’ at each layer?

A:

• Physical: Tapping (도청)
• Link: break in and listen/interfere 와이파이, 이더넷
• Network: break in and listen/interfere 라우터, 게이트웨이, 모뎀, 방화벽
• Transport: see/modify 어플리케이션 대화
• Applications: for access to content or to interfere

Q: The idea behind encryption is mainly seen as providing confidentiality. Why do we have both SSL/TLS and IPSec, if they do pretty much the same thing?

A:

• SSL/TLS 와 IPSec 은 서로 다른 계층에서 실행된다 (트랜스포트, 네트워크) 따라서 다른 특징을 지님
• TLS는 어플리케이션의 기밀성을 책임지지만, 여전히 출발지, 목적지, 포트 등의 정보를 드러낸다
• IPSec 의 경우 본래 패킷에 대한 모든것을 숨기며, 터널을 제공함으로써 src / dest 에 대한 정보를 숨김
  • 또한 IPSec의 경우 어플리케이션 계층을 커버하는 반면, TLS는 오직 어플리케이션만을 책임짐

Q: What does it mean to have ‘confidentiality’, ‘authenticity’ and ‘integrity’ of packets traversing the network? What about ‘freshness’?

A:

• Confidentiality: 아무도 듣지 못함
• Authentication: 상대방이 주장하는 신원이 확실하다고 믿음 (즉 본인확인)
• Integrity: 패킷이 중간에 변질되지 않았음
• Freshness: 패킷이 새로운것이며, 재사용되지 않음

Q: Why does TOR (onion routing) use 3 routers for passing traffic through?

A: 아무도 한번에 어디서 어디로 향하는지 알게 하지 못하게 src & dest. 이로 인해 그 누구도 양 종단에 대한 정보를 알지 못함.

• Guard: Knows src
• Middle: Knows nothing
• Exit: Knows dest

Q: Why would a worker on the road use a ‘mixed-mode’ VPN connection to their office? What’s the benefit, compared to say a ‘transport-mode’ VPN?

A:

• Mixed-mode 란 호스트와 라우터 같이 다른 기기가 연결된 모드를 말한다
• 이로 인해 이 호스트는 라우터에 속한 다른 기기들에게 마치 같은 LAN에 속한 기기처럼 보여질것
• Transport Mode 는 호스트와 호스트를 직접적으로 바로 연결한다.
• 차이점은, 만약 해당 대화가 (communication) 이 point to point 형식이라면 Transport 모드를, 여러명과 대화해야 한다면 mixed-mode 가 더 적절하다.

Q: How does ingress filtering prevent (most) spoofing?

A:

• 라우터의 경우 해당 패킷이 어디서 온건지 알 수 있다.
• 예를 들어, 어느 패킷이 항상 어느 네트워크에서 오는지 알고 있다면, 다른 곳에서 오는 (특이하게도) 패킷의 경우 필터링이 가능한것.
• 이전과 다르게 다른 네트워크에서 온 패킷을 마치 spoofing 처럼 고려해서 그냥 드롭해버림.

Q: What are some the network feedback sources that help tell you when things are going badly somewhere on the network? 네트워크상에 안좋은 일이 일어나는지 어떻게 알 수 있나?

안 좋은일: 혼잡…?

A:

• ICMP: 다양한 이유로 안 좋다는 사실만 알 수 있음; MTU가 너무 낮을수도, 높을수도 등등
  • IP 의 경우 신뢰성이 없으며 비연결 지향적이기에, 이를 보조하기 위해 ICMP 가 등장
• ECN: 라우터가 혼잡이 생겼음을 알려줌, back off 해야 할지 알려주는 기준임
• TCP Feedback (flow control) such as ACK Clock, SACK info, Jitter+latencry
  • ACK clock - ACK 가 오는 속도가 줄어드니까 알수 있음
  • SACK - 놓친 패킷에 대해 ACK 가 반복되니까 손실이 발생한지 알수 있음
  • Jitter + latency - 패킷 별로 도착하는 시간이 (variation) 다르니까 알 수 있음

Q: Why can’t we use all that feedback to measure what is going everywhere?

A:

• 왜냐하면 각각의 피드백은 그 path에 관한 내용인데, 이 경로가 고정된것도 아니고, 우리가 어떻게 조절할 수 있는것도 아님.
• TCP feedback 들 또한 전체 경로중 혼잡이 발생한거지, 특정 경로, 위치에 대한 내용을 포함하고 있지 않음
• 결론: 정확한 위치에 대한 피드백을 받는것도 아니며, 그 위치를 알아도 고칠수 있는 방법이 없음

Q: What problems does SNMP solve?

A:

• 내 경로에 속하지 않은, 혹은 내 어플리케이션과 대화 하지 않는 네트워크 요소 (기기) 에 대한 상태를 확인 할 수 있게 해줌
• Provides data that is standardised and that you can aggregate
  • 이는 혼잡, 에러, 다른 문제들을 detect 할 수 있게 해준다. 특히 어느 기기가 문제를 일으키는지 모든 경로를 탐색하지 않아도 바로 알수 있음 (왜냐면 해당 기기의 상태를 확인만 하면 되니까)
• IP 를 통해서는 알 수 없는 기기의 상태 (온 오프), 혹은 이벤트 발생등을 알 수 있다
• 물론 이를 가능케 하기 위해, 해당 네트워크 요소가 SNMP agent (or server) 기능을 가져야 한다
• 최근까지 보안도 안 좋았음.

Q: Why doesn’t it solve all those problems across the width of the Internet?

A: 내부 인터넷에 대한 정보를 알려주기 싫으니까. 덕분에 내가 권한이 있는 네트워크에 대해서만 사용 가능하다.

Q: Why do we want views over time and space?

A:

• Views over Time (기간동안 살펴보는거) - 패턴
  • 시간적으로 지켜봐야, 이 behaviour 가 정상인지 비정상인지, 혹은 우리가 보고 있지 않을때 일어났는지 알 수 있게 해줌.
  • 혼잡이 짧은 시간동안 버스트 형태로 일어난건지, 아니면 해당 시간에 단순히 유저가 너무 많아서 expand 가 필요한건지 알려줌
  • 즉 시간적으로 지켜봐야, 해당 행동의 정상 유무와 이를 해결하기 위한 방법을 알 수 있음
• Views over Space (순간 순간 공간 (상황) 을 지켜보는거)
  • 현 네트워크 상황의 스냅샷을 제공해주며, 이로 인해 우리가 지금 해결해야 하는 문제가 있는지 알려줌
  • 예를 들어 어느 링크가 다운되었다 는 공간적 입장에서 현 상황이므로 해결되어야 함.

Q: Why does an SNMP trap get sent, and by whom?

A:

• agent 가 manager 에게 보내는데, 이는 어떤 중요한 이벤트가 발생 했다는것을 알리는 알림이다
• 매니저로부터 요청받는 보통의 쿼리/응답 메세지가 아닌 6개 이벤트 (링크 다운업 등등) 이거나 제조사가 정의해 놓은 이벤트가 발생한것.

Q: What’s the point of a MIB?

A:

• MIB 는 데이터베이스의 구조로, 다른 MIB 와 합쳐 질 수 있음 (나무 형식). 이로 SNMP agent 가 가지고 있는 데이터에 대해 모든 object는 unique 한 이름을 가질수 있다
• MIB는 각각의 필드, 구조, 성격, 관계들을 정의 하며, 사람들이 읽을수 있는 설명도 포함하고 있음

Q: What is a ‘GetNext’ used for?

A:

Lexicographical order of OID Tree - 곱집합에 위지하는 부분 순서

즉 밑의 사진의 경우 Interface 와 ipAddress 사이의 숫자 부분을 말함.

• Get 요청은 SNMP에서 굉장히 구체적인 명령어로, MIB 에 존재하고 있음을 알아야 함
• 따라서 Get으로 비슷한 관련 데이터를 읽기 위해서는 모두 각각의 위치를 알고 있어야 함 (행열 모두).
• The SNMP GETNEXT operation is similar to the SNMP GET operation. The GETNEXT operation retrieves the value of the next OID in the tree. The GETNEXT operation is particularly useful for retrieving the table data and also for variables that cannot be specifically named. It is used for traversing the MIB tree.

Security?

• 뭐가 위험한가, 공격자가 어떠한 능력을 가졌는가, 비용과 임팩트, 그리고 확률은 어떻게 되는가
• 리스크를 알기 위한 모든 도움과, 이 리스크를 피하기 위한 모든 노력들이 필요함

다양한 공격 방법들이 존재한다

• eavesdropping : 메세지 중간에 가로채서, 안에 내용 파악하는거 (passive)
• Intrusion: 기기를 공격해서 메세지를 변질 시킴 (active)
• Impersonation: identity fraud, 컨텐츠 파악, 내용물 면질 (active)
• Extortion: 서비스 방해 (active)

Vulnerabilities

• 공격 surface: 얼마나 많은 부분이 공격 가능한가, 이를 어떻게 아는가?
• single point of failure: 한 기기를 통해 공격 가능한가?
  • 라우터, 서버, 디렉토리, 데이터베이스, 파일 등 한가지 point로 날 공격 가능한지

결국 보안은 리스크 매니지먼트와 같은것

• 절대 완벽할 수 없고 (왜냐면 부족함을 증명하기 쉽지 않음)
• 단지 확률을 줄이기 위해 보안 모델을 확실히 할뿐
• 또한 보안은 가장 약한 링크만큼만 안전하다 (걔가 뚤리면 그냥 그만큼 안전한거)

여러가지 flaws들이 존재하는데

• Design Flaws: Law of unintended consequences (multi-component system)
  • 의도하지 않은 결과: “이러면 안되는데…?” 왜냐면 인터넷은 여러가지 시스템이 존재함
• Code Flaws: 항상 버그는 존재하지
• Somebody’s flaws: 사람이 (의도하던 아니던) 문제를 일으킬수도 있고 다른 이유도….

Wifi

• Old WEP cryptography - easy to snoop and decrypt
  • 64, 128 비트를 사용해서 키 값이 일정해서 보안에 취약함
• 802.11I came out to fix old WEP
  • Impossible to brute-force decrypt
  • Removed one threat but
    • 예상 가능한 SSID/Key - get attacker on the WLAN
      • 패스워드 예상 가능
    • wired LAN access to devices on WLAN - get attacker on the LAN/WLAN
      • 해당 인터넷에 접근 가능한 기기에 선 꽂으면….
    • 네트워크 디바이스 (access point)에 대한 물리적 접근 - AP boards 에 chip 설치 등등
      • 해당 인터넷에 접근 가능한 기기를 하드웨어적으로 바꾸는거

즉 하고자 하는 말은 우리가 아무리 무선을 암호화 해봐야, 해당 네트워크에 접근 하는 방법은 여전히 존재함

안일한 인터넷 디자인 (어플리케이션 계층 위주)

• 수년에 걸쳐 보안이 추가되었음
  • 처음 프로토콜들은 조그맣고, 서로 친밀한 커뮤니티 사이에서 쓰이도록 먼저 만들어졌었음
    • DNS, DHCP, HTTP 모두 요청하면 들어줬음
    • 즉 클라이언트와 서버가 서로 미리 알고 있던 관계였음
  • 메일이 친한 대학간에만 사용되었던것 처럼
• 초기 디자인은 이로 인하여 네트워크가 전달하는 내용에 대한 중요도를 고려하지 않았음
  • 서로 아는 사이인데 무슨 보안이야 (인터넷으로 대화하는거 자체가 신선했던 시기)
• 따라서 이후 보안을 추가하기 위해 굉장한 노력들이 필요해짐
  • 아예 처음부터 보안을 위해 다시 디자인을 하던가
  • 아니면 보안을 위해 다른 메커니즘을 추가하던가

아이피 패킷 (네트워크 계층)

• 종단간의 메세지 전달을 위해 다양한 방법, 경로를 통해 전달된다
• 헤더, 그리고 페이로드 또한 믿지 말아야 한다.

기본 가정들

• 누군가는 항상 나쁜 목적을 가지고 있다
• 모든 물리적 링크들은 여러가지 방법으로 방해될 수 있다 (스누핑, 미스다이렉트, 컷,등등)
• 프로토콜 디자인은 공공적이며 많은 헛점을 가지고 있다
• 와이어에 대한 보안은, 호스트에 대한 보안으로부터 뚫릴수 있다
• 기술은 해킹하기 쉽지만, 사람은 더 쉽다.

암호화는 다음과 같은 사항을 고려한다

• 고려해야할 데이터의 상태는
  • In motion: 움직이는 데이터의 보안 (네트워크 통과하는 중)
  • At rest: 저장되어 있는 데이터의 보안 (어플리케이션, 보관소)
• 반드시 eavesdropping 을 위해서만을 위한것이 아니다 (confidentiality/privacy)
• 다음과 같은 사항을 체크하기도 한다
  • 기다리던 기기로부터 도착했는지 (인증)
  • 기다리던 원격 파티로부터 도착한게 맞는지 (인증)
  • 해당 메세지가 정확하게 맞는지 (체크섬) - integrity
  • 해당 메세지가 전에 보내졌지 않은지 (중복인지?) - 이거 안하면 replay 공격 당함

암호화 방식

• Shared Secret: Both has the same key
  • 양쪽 모두 같은 알고리즘을 사용하며, 공격자가 이 알고리즘을 알고 있다고 가정하는게 좋다
  • 따라서 한 키를 공유하는것은 약점에 속한다
• Public Key: Key pair - public/private
  • 오너가 private key를 가지고, 아무나 public key를 사용할 수 있음
  • RSA 같이 복잡하고 비싼 (계산적으로) 암호화 형식을 사용한다
  • Public key Infrastructure (PKI)를 사용한다.

위와 같은 trade off를 좋게 이용하기 위해

1. public key를 이용하여 shared key를 보낸다 - private key를 가진 소유자만 decrypt 할 수 있으니까
2. shared key를 이용하여 추후 커뮤니케이션을 암호화 한다 (기밀성 보장)
   • 이 shared key = session key이다
     • 짧은 기간동안 매 패킷에 사용된다
     • 크기도 상관이 없다 (키 숫자 말하는듯)
     • 빠르게 키를 바꿀수도 있다.

즉 “야 나랑 이야기 하려면 이 shared key 통해서 암호화 해서 보내” 위에서 말했는 shared key가 계산적으로 싸고 빠르기 때문에, 이 shared key를 안전하게 보내는 비싼 계산 방법인 public private 은 처음에만 쓰는거.

세션 키

Authentication and Integrity

Authentication : 해당 사람에게서부터 해당 인원에게 도착한건지 (인증)

Integrity: 해당 메세지가 변질되지 않았는지 (무결성)

• Confidentiality 는 수동적인 빌런들에게 굉장히 효과적이다
  • 수동적인 빌런들은 패킷을 읽지 못하며, 자원들을 autheticate 할 수 있어서 안전
• 능동적인 빌런들은 메세지가 전달되는 과정을 노릴수 있다 (intruder)
  • 이로 인해 잘못되고, 오해되고, 혹은 고장난 메세지가 전달 될 수 있다
  • corrupt, replay, reorder packets.
    • WAIT DO NOT STOP —> STOP DO NOT WAIT 과 같이 말이다
• 이로 인해 message integrity가 필요한것
  • 세션 키를 사용한다 (PKI를 통해 세션키를 생성)
  • 메세지의 서머리를 계산한다 (시그네쳐, message digest, hash…)
    • 서머리를 세션키/개인키 를 이용하여 암호화 한다.

Freshness

Replay attack: 공격자가 해당 메세지를 가지고 계속해서 보내는식의 공격이 가능하다

• 예를 들어 A로 100불 보내기 를 여러번 보내는등

물론 이 공격은 timestamp를 메세지나, 시그네쳐에 적어두면 무력화 시킬수 있다 (물론 암호화 시켜야함)

암호화 사용하기

• 각 어플리케이션은 이제 스스로 다음과 같은 사항을 프로토콜에 적용할 수 있다
  • confidentiality
  • authetication
  • integrity
  • freshness
• 물론 우리는 개발자, 언어, 운영체제들을 믿지 않음으로 네트워크에도 적용한다

네트워크 보안

SSL - Secure Socket Layer

HTTP의 보안을 위해 만들어짐 → HTTPs

또한 Transport Layer Security (TLS) 를 generalize 하는데 공헌도 함.

→ Between transport and application layer: encrypts TCP payloads

• SSL/TSL (TSL is SSL 3rd version edited one) provides
  • 클라이언트에 의한 서버 확인 절차
  • 메세지 교환 (기밀성, 무결성, 인증, freshness)
• 인증 phase로 시작한다
  • 암호화된 채널과 세션키를 생성하기 위해 인증부터 시작
  • 그 전까지는 어느 한 메세지도 교환되지 않는다
• 클라이언트는 새로운 (랜덤한) 서버를 인증해야 한다
  • 네트워크 트래픽이 spoof and misdirected 될 수 있기때문
  • 서버 public key, 그리고 인증된 CA 가 필요하다

이 밑의 SSL의 간단한 순서를 보면 알 수 있다.

1. Handshake - 처음 세번은 TCP와 같이 똑같이 핸드셰이크를 한다 (세션 빌드)
2. 헬로 메세지를 보내고 상대방은 공개키와 인증서 (CA)를 보내온다
   1. 따라서 우리는 상대방이 올바른 사람이라는것을 알수 있다
3. master secret key (MS)를 생성후 받은 공개키를 이용해서 상대방에게 보낸다
   1. 상대방은 자신의 private key를 이용해 decrypt 한다

— 이제 양쪽 모두 MS를 가지고 있다 —> 모든 암호화와 데이터 무결성 검사를 위한 대칭 세션키로 사용된다.

물론 한가지만을 이용하면 위험하니, 특별한 방법을 거쳐서 암호화 키, 세션 MAC (무결성 검사) 키를 두개씩 총 네가지를 만들어낸다 —> 총 네가지의 세션키를 공유하고 있는것.

Public Key Infrastructures

• 인증서 발급, 인증서 관리
• 인증서 배포, 인증서 사용
• 인증서 저장, 인증서 취소
• CA = Certification Authority
• RA = Registration Authority
• VA = Validation Authority

단 한가지 Certificate Authority는 당연히

• 너무 많은 유저 (네트워크) 를 상대하기 쉽지 않으며
• 한번 실패하면 큰일나며
• 타겟 되기가 너무 쉽고
• 만약 이 authority가 corrupt 해서 독주체제로 가면 믿을수 없어짐

따라서 이를 방지하기 위해 레벨별 다양한 CA를 가진다

• 크롬의 경우 70여가지의 CA 를 가지고 있으며
• SSL/TLS initiation 의 server CA 또한 다양하게 확인한다.

물론 이러한 인증 절차는 상대방이 해킹을 당했으면 다 쓸모 없음 (이미 해킹해서 다 아니까)

• private key 가 이미 해커에게 털렸고
• Certificate 은 반려가 되어야 한다 (털렸으니)
• 이러한 상황을 위해 PKI는 Certifacite Revocation List (CRL) 을 소지하고 있으나, 이런 일은 자주 일어나지 않음

또한 DNS 는 UDP base 임에 따라 spoofing 이 쉽다.

DNS Poison (pharming)

DNS의 경우 Nameserver가 해당 도메인에 대해 아이피 주소를 물어보는 형식임

또한 DNS는 단 세가지만을 체크하는데,

1. 알려진 서버로부터 온 응답인가
2. 아이디가 동일 한가
3. 현재 물어본 쿼리에 대해 해결책을 제시하는가?

따라서 이 안의 내용에 대해서는 전혀 관여를 안한다. 즉 위 세가지 방식을 만족한다면, 잘못된 주소를 알려줘서 유저가 감염된 사이트로 방문하게 만들수 있는것.

이 응답은 여러곳에서 오는데, 제일 먼저 오는것만 채택하고 후의 것들은 무시한다.

따라서 해커의 응답이 제대로된 서버의 응답보다 먼저 도착 한다면, 제대로된 서버 응답의 경우 무시되는것.

DNS 보안은 기밀성에 대한것이 아닌 integrity and authentication 에 중점 (위 해킹이 authentication의 부족에서 온것을 기억하자)

내용의 기밀성은 상관이 없다. 맞기만 하면됨.

DNSSEC:

• RRSIG - 도메인 레코드 셋 (배운 A, AAAA, MX 등등)에 대한 디지털 서명
  • 즉 이 데이터 셋은 이 디지털 서명에 의해 보장됩니다! 이런거
• DNSKEY - RRSIG를 위한 public key
  • (Zone Signing Key (ZSK) and key signing key (KSK)
    • KSK >> ZSK 인데 이는 네임서버의 키-체크 부담을 줄여주기 위해서이다.
    • KSK, ZSK 둘중 하나를 사용한다. Zone 의 공개키로 사용된다.
  • ZSK : Zone 의 모든 RR 서명에 사용되며, 암호화 비트와 기간을 짧게 사용
  • KSK: ZSK를 서명하기 위해 사용한다. Zone의 Security entry point 로 사용됨 (암호화 비트와 기간을 길게 사용한다)
• DS (Delegation server key) - public key for delegated zones
  • 부모 자식간에 인증 사슬을 형성하며, KSK를 사용하여 신뢰사슬을 만들어 부모 zone 에 제출

다음과 같은 사항들을 필요로 한다

• 암호화 오버헤드 감소

  • DNS는 매우 유명한 프로토콜이며 항상 사용되기 때문에 딜레이를 최소화 해야함
  • 또한 다른 암호화 기술이 사용될수 있도록 해야함 (개방적)

• 다른 Resource Record (RR) - NSEC (next secure record)

  • DNSSEC의 일환으로, 해당 레코드가 non-existence 한지를 체크하기 위해서 사용된다 (즉 해당 레코드의 존재 확인을 위해 존이나, 타입 리스트에 대한 링크를 가지고 있는것)

    부정적 대답에 사용된다. 즉, 네임이 존재하는지에 대한 증명에 사용된다.

  • 실제로 질의한 도메인이 존재하지 않는 도메인이거나 레코드가 존재하지 않는 경우 zone내에 각 도메인들을 sorting하고 그 순서에 맞는 domain을 NSEC으로 응답

  • NSEC3는 Return되는 도메인을 Hash 함수처리

  • 이는 zone information을 유출한다.

DNSSEC 이 반영된 DNS 절차

• 똑같이 네임서버에 대해 쿼리 하는것으로 시작한다
• 온 답변들을 인증을 이용하여 validate 한다
  • Top to Bottom 형식이며 PKI chain of trust 이다
  • 또한 사실상 root 는 검증하기 불가능하므로, 검증되었다고 가정하고 질의를 시작한다
    • 이를 anchor on root public key 라고 말한다. root 공개키를 가정 (anchor) 해서 시작하니까
  • 각 도메인을 타고 내려가며 각 도메인또한 관련 키를 사용하여 검증한다.

모든 DNS 들이 사용하지는 않는다 → 늘어가는 추세이나 아직 100프로 아님

SSL/TSL 은 어플리케이션과 네트워크 계층 사이의 보안을 보통 담당하는데…

• 마찬가지로 여러번 이미 뚫렸음
• 코드, 암호, 혹은 프로토콜간의 접촉 등등 여러 이유로
• 모든 어플리케이션이나 다른 계층들이 모두 사용하는것도 아님

Firewall

패킷들을 막아내는 edge (보더) 라우터, 게이트웨이, 프로세서들

Middlebox

라우터는 보통 IP만 검사하지만, middle box역할도 겸하고 있다.

Packet Filter 는 다양한 방식의 정책으로 가능하다. 또한 각 패킷당 개별적인 검사를 시행한다 (stateless)

이는 연결에 대한 state가 아닌 각 패킷은 항상 검사 된다는것

• IP주소 기반
• UDP/TCP, ICMP, OSPF … 등등 프로토콜 기반
• 포트 넘버 기반
• TCP flag bits, ICMP message type 등등

Stateful packet filter:

state는 패킷이 아닌 연결에 대한것을 상기한다 (연결이 안에서 밖으로 시작되어야함)

⇒ 그래서 reverse_https 같은 기법들이 존재하는거.

• 패킷 플로우를 내/외부 차이점을 기준으로 검사하는 방법
• 예를 들어 NAT의 경우:
  • 내부에 있는 Y가 시작하여 만들어진 TCP 연결에 대해 외부의 X가 Y에 대해 패킷을 보내는것을 허용
  • 즉 TCP연결은 안에서 밖으로만 initiate가 가능하고, 바깥에서 안으로 들어올때는 해당 테이블을 보고 연결 검사를 진행해야 한다.
• 안에서 밖으로 연결 시행이 가능하기에 모든 연결은 테이블에 기록이 가능하다.

Application Firewall - Deep Packet Inspection

• 어플리케이션 프로토콜을 이해함
  • 메세지를 확인후 다시 재조립하여 해당 목적지로 보내줌
  • 컨텐츠를 이해한다 (즉 이메일, 웹페이지 바이러스 검사가 여기서 이루어지는것)
• 물론 해당 패킷을 열어보고 검사후 버리기때문에 (여태는 걍 버렸음) 퍼포먼스 하락이 이루어짐

왜 가능하냐면, 메세지 자체는 이미 최종 목적지, 어플리케이션에 도착해서 다 풀린 상태임. 이 방화벽이 하는 역할은 이 decrypt 되어서 우리한테 최종 전달되기 직전에 검사를 하는것.

또한 기기마다 중요도가 다르기 때문에 여러 단계로 나누어서 다른 레벨의 방화벽 설정도 가능하다. 방화벽 간의 사이를 DMZ라고 부른다

Firewall Implementation - 설정 방법

• 허용된 기기들 : 특히 어플리케이션/DPI 방화벽
• 라우터/ 모뎀
• Wireless access points
• OS based hosts - 리눅스 아이피테이블 (리눅스 기반 아이피 테이블) 패킷 필터

여러 방화벽을 사용할 경우 당연히 더 많이 신경써야 하고 느려지지만, 내부의 공격도 막을수 있으니 장단점이 존재

Firewalls = Islands of trust

• SSL 은 모든것을 숨기지 않는다
  • 중간 라우터들은 트래픽을 볼 수 있음 (활동에 대한 정보가 새는것)
• Leased Lines (내 개인망) - 이러면 트래픽을 숨길수 있음
  • 효과적이지만, 돈도 들고 (즉 크게 못함), 해당 라우팅에 대한 설정도 따로 필요함

따라서 SSL의 단점과 Leased lines의 단점, 즉 트래픽의 노출과 비용부담을 모두 보완하기 위해 아이피 (네트워크) 레벨에 보안을 적용해서 virtual leased line 을 만든다 ⇒ Virtual Private Network

Islands of trust - VPNs

사설망 (LAN) 처럼 공용 인터넷 망을 사용하는것. 하지만 ISP를 사용하되 이 ISP가 보지 못하도록 따로 암호화 기법과 해당 라우터안의 체계나 기법등을 비공개 하는것.

VPN은 그냥 각 컴퓨터나, 라우터가 IP 데이터그램을 암호화 시켜서 보내는거.

이 VPN으로 이루어진 암호화가 진행되는 기간이 터널링이다.

https://travelerstory.tistory.com/91#:~:text=IPSEC(Internet Protocol Security)은,된 인터넷 보안 표준입니다.

Modes

Tunnel (=encapsulation) IP packets across the internet (IP in IP)

물론 단순한 터널링은 아무런 보호성도 가지고 있지 않음, 그냥 헤더만 하나더 붙임

• No confidentiality, authentication, integrity

IP Security 을 이용해서 VPN connection 을 secure 하게 establishment 하는것

• 네트워크 레벨에서의 암호화
• 종단간의 (호스트, 라우터) 키 공유
• 패킷의 캡슐화및 보호화

VPN Endpoints 는 위에서 말했든 호스트, 라우터 두개의 종단간에 가능하다

• Tunnel Mode: Router and Router (with forwarding)
  • 모든 서브넷을 투명하게 연결시킴 (하나처럼 보이게 터널로)
    • 라우터간 연결되었으니 서브넷 두개가 하나처럼 보이는것.
  • NAT friendly (라우터가 관리 터널끝이니까, 요즘 NAT은 라우터에 같이 있음)
  • New IP header는 라우터의 주소이다 - 종단 라우터에 도착하면 (터널끝), 패킷 풀어서 해당 기기에 보내주는것 (즉 터널 밖으로 나오지 않는 이상 어디로 가는지 모름)
• Transport Mode: Host and Host (no forwarding)
  • 다른 포맷으로 오직 IP payload만 암호화 한다 (라우터 합침을 통한 서브넷간의 통합이 아닌 두 호스트간의 LAN 같이 사용하는거)
    • 이로 인해 트래픽이 어디서 어디로 가는지 경로가 유출됨 (최종 목족지)
  • 문제는 해당 아이피가 NAT 에서 사용되는 경우 사실과 다를수 있기 때문에, 이를 위한 PSK를 통한 인증이 필요하다. 그렇기 떄문에 NAT challenge

내가 헷갈려한 것은, VPN 서버를 이용할 경우 (나라 장벽떄문에) 이게 어떻게 진행되냐는건데,

VPN을 통해 나라 장벽을 우회하려면, 해당 VPN 서버에 대해 터널 모드를 만들어서, VPN 서버에 도착하면 내 원래 목적지 주소를 알려주고 거기에서 다시 목적지로 향하는것 (해당 VPN 서버에서는 무슨 모드이건 그건 이제 선택사항임).

장벽 우회같은 이유가 아니면, 그냥 공공망 바로 터널이던 전송이던 알아서 쓰면됨.

AH 는 기밀성을 보장하지 않음, ESP는 다 보장함.

ESP(Encapsulating Security Payload)

새로운 데이터 IP Packet을 만들고 기존 IP Packet을 Data Payload에 넣어 감싸는 방식

• AH (인증) 가 가진 무결성과, 인증도 제공하고 추가적으로 대칭키 암호화 (PSK) 를 통해 기밀성(Confidentiality) 제공

Tunnel Mode

즉 위의 터널 모드는 애초의 목적지인 IP header 까지 암호화 시키니, 미아가 되지 않도록 터널링을 담당하는 장비 (라우터) 의 아이피를 적어서 보낸다. 즉 라우터간 (터널) 동안에 기밀성이 보장된다 (물론 이 라우터로 가고 있다는 트래픽 경로의 경우 유출이 되니 - 어느정도의 기밀성이 보장된다 가 알맞다).

따라서 해킹을 위해서는 A, B 혹은 라우터 장비의 물리적 회선망 (A나 B로 향하는)에서나 가능하다.

터널내에서는 esp가 존재하므로 암호화에 따라 해킹이 매우 힘들다

Transport Mode

만약 해당 네트워크가 NAT를 이용하면, 수신자 측에서 검증시 인증에 실패 할 수 있기에, PSK를 사용하여 서로 인증을 해야함 (그래서 NAT Challenge )

또한 전송 모드는 단대단 간의 연결 (TCP 처럼) 을 보호해주기에 Transport layer의 보안으로도 사용될수 있다.

터널 모드와 다르게 전송 모드는 패킷 페이로드만 보호해주며, 이로인해 경로 유출이 일어난다.

아까 위에서 말한 헷갈린점은 VPN 사설 서버를 이용하는 경우에 터널 모드를 사용하니 결국 어디로 가는지 모름 공용망 시점에선.

VPN 주의점

• 이 종단 라우터 또한 반드시 해당 기기에 가장 가까운 라우터라는 법은 없음. 단지 그냥 터널링을 끝내는 라우터에 불과함 (즉 해당 라우터에서 해당 기기까지 가는데 다른 라우터를 지나갈수 있음)
• 따라서 end-point에서부터는 누가 누구에게 이야기 하는지 알수 있음
• 보통 아이피는 위치에 따라 지정된다

결국 터널링이 끝나는 순간 보호되지 않은 트래픽이 된다 → 여전히 보안의 위험성 존재

따라서 이러한 상황을 더 나아지게 하기 위해 더 많은 터널링을 하는식으로 보완한다.

Onion routing = onion encryption

• 랜덤하게 세가지 노드를 선택한다 - 가드/미들/출구
• 클라이언트는 해당 세가지 노드에 대한 public keys를 가지고 각각에 대해 세션키를 만든다.
• 클라이언트를 각각의 세션키를 이용해 모든 패킷들을 암호화 한다 + 서버가 필요한것 포함

물론 이 방식은 세가지의 중간 노드만 정확히 지정해 둔거고, 이 노드를 방문하는 라우팅 알고리즘은 공용망에 맡긴다 (알아서 데려가줄텐데, 이 세 가드 미들 출구만 정확히 지나가면됨)

따라서 이는 MPLS (multi protocol label switching) 과는 다음과 같은 이유로 다르다

MPLS는

• 미리 모든 경로를 지정해둠 (onion 의 경우 세개만 지정)
• 패킷들은 토큰으로 레이블되어 있음 (onion은 세션키로)
• 경로중 하나만 죽어도 다 실패함 (onion은 맨끝만 죽으면 실패한다 - 주는사람 or 받는사람)

Physical Security

Device Security

• 스위치와 라우터는 물리적이고 가상적인 인터페이스를 가지고 있음
• 원격 엑세스
  • SNMP agents (HTTP)
  • OS (Telnet ssh)
  • Port monitors and mirrors
    • 다른 포트에 대한 트래픽을 반영하며, 바깥에서는 알수 없는 정보
• 물리적 엑세스
  • 인터페이스 재정렬 (denial) 혹은 공격
  • 케이블 절단, 방해
  • 칩 레벨 스누핑

Copper Security

여기서 말하는 보안은 이를 이용한 데이터 보안이 아닌, 말 그대로 코퍼에 대한 보안임

attenuation등이 원래 발생하는 라인이기에, 문제가 생겼는지 발견하기가 쉽지 않음

자르기도 편하며, 누군가 케이블 자체를 (라인이던 쉴드던) 건드리면 denial of service (noise, antenna, energy loss) 등이 발생함

Fiber Security

코퍼에 비해서는 발견하기가 쉬운데 케이블 특성상 loss 가 발생하기 어렵기 때문

물론 선 절단이던 tapping (금가거나 등등) 은 코퍼와 마찬가지로 쉽게 발생한다. 그래서 NSA에서 해저 밑바닥에 깔아둠.

Wireless Security

• 무선은 특성상 브로드케스트 이기때문에
  • 좁은 beam 안테나와 짧은 wavelength 가 도움이 된다
• 빌런들이 듣고있으며, 적극적으로 intrude 할 수 있음
• 물론 access 에 관한 말이고, 해당 패킷이 암호화가 잘 되어있는거는 다른 이야기

802.11

기기와 wifi 사이 (무선연결) 의 payload에 대한 암호화를 책임지고, 해당 데이터가 와이파이 라우터에 성공적으로 전달되면, 해당 암호화를 풀고 선 (물리적)을 이용해서 목적지로 전달한다

즉 무선 기기간의 암호를 책임지는 프로토콜임

Wifi Network Keys

Layer 2

• 클라이언트가 AP에게 인증한다
  • 클라이언트가 AP에게 요청하면 AP가 수락하고, 등록후에 더 많은 키를 나누어준다
  • 각각 SSID password (pre shared key -PSK)로 부터 얻은 공유 세션키를 계산한다.
    • 이 공유 세션키를 이용해서 PMK, GMK 를 생성하고 이 마스터 키들이 이후의 PTK, GTK 유도하기 위해 사용되는 보조키 역할을 한다.
    • 여기서 만들어진 Pairwise Transient Key (PTK) 를 무선구간 암호화를 위해 사용한다
• AP to Clients (broadcast/multicast)
  • Group Temporal Key 를 이용하는데 마찬가지로 무선구간 암호화를 위해 사용한다.
  • PTK와 다르게 브로드캐스트, 멀티캐스트용이다.

1
2
3
4
5
6
7
8
9

구분 
     - 4-Way Handshake
        . Pairwise Key,Group Key 생성을 위함
     - Group Key Handshake
        . 이전에 4-Way Handshake을 통해서, PTK 및 GTK를 확보한 STA에게,
          Multicast/Broadcast용 데이터 암호화를 위한 GTK를 분배하기 위한 2-Way Handshake 임
        . 사실상, 위 4-Way Handshake에서 끝에 있는 2번의 메세지 교환 단계와 동일함
     - PeerKey Handshake 
     - TDLS PeerKey Handshake

원래는 Station - AP - Authentication server 로 이루어져야 한다.

1. AP 가 클라이언트에게 제공 가능한 서비스들을 알려줌
2. 먼저 서로 인증을 위해 EAP 를 이용해서 메세지를 전달한다. 클라이언트와 무선은 EAPOL을 통하고, 무선과 인증서버는 RADIUS라는 프로토콜을 이용해 인증한다. 이 과정중 마스터 세션 키를 생성한다
3. 마스터 세션키는 클라이언트와 인증 서버만 가지고 있는데, 이를 이용하여 PMK를 만들고, 인증서버가 이를 AP 에게 보낸다.
4. PMK를 이용하여 PTK를 생성한다.

802.11i [정보통신기술용어해설]

Wifi Encryption

WEP: 64 bit, 128bit 등을 이용해서 암호화키를 생성해 보안을 유지하지만, 이 키값이 일정한 값을 유지해서 취약점이 노출되었음

WPA: Use of PSK (password)

• 더 나은 integrity 체크가 가능함
• Temporal Key Integrity Protocol (TKIP) - 프레임별 키
• WPS로 인해 뚫릴수 있음

Denial of Service

• Ping of death (3)
  • Large ICMP packet, multiple fragments, modified headers.
  • 메모리 오버 플로우 일으킬 수 있음
  • 호스트에 대한 직접적 공격
• SYN Flood (4)
  • 서버에 TCP 연결 생성하고 해당 SYN/ACK 를 따르지 않고 마구잡이로 보냄
  • 이로 인해 서버는 connection state를 유지해야함 (왜냐면 얘가 뭔지 모르니까 각각 하나씩 생성)
  • 이 방식은 SYN 쿠키를 사용하면 피할수 있음 (즉 커넥션을 ACK이루어진 이후에만 생성하는것)
• Application layer messages:
  • 복잡한 쿼리들 (complex regex or big database queries) 보내기
  • 메모리 오버플로우
  • 다른 버그들
• Spoofing
  • 다른 컴퓨터를 이용해서 공격하는 방법
  • 예를 들어 공격자가, 나는 A이고 B야 메세지를 보내줘 하고 B에게 보내면 B는 A에게 메세지를 보내는 방식
  • Ingress filtering 은 중간에 이 공격자가 A인지 확인하는 절차를 넣는것이다.
    • 물론 소스는 확인 불가능하고, 단지 해당 네트워크에서 보내진것인지 확인하는것
    • 즉 내가 A (네트워크 1) 라고 주장하면서 해당 아이피가 네크워크2에서 오면??
    • 근데 아직 대중화는 안됨
  • Host multipliers: Zombie host 같은거
  • Packet multipliers: Small requests, big responses
    • DNS: “I want the entire list of this” - 리스트 크기가 큼
    • HTTP/FTP/NFS… : “Send me 10GB file”
    • Memcache servers: Database accelerators over UDP
  • SMURF:
    • 브로드캐스트 주소를 핑함
    • 목표물의 아이피 주소를 자원으로 삼음 (spoof)
    • 모든 사람들이 해당 아이피에 답변을 함 (many packets are back)
    • 물론 이 방식은 prevent 하기 쉬움

Mitigation - DoS 피하는 방법 (매우 어려움)

• Content Distribution Networks : Dont be a single target
• Edge Routers/Attacker Detection: 효율적인 패킷 드롭, 좋은 필터링 셋팅 (한명이 담당/ 공격감지)
• Upstream provider support: 다른 방향으로 돌려버리기 (re-route)
• Ingress Filtering: 네트워크 레벨 확인 절차

그래프 기본 용어

Fowarding vs Routing Table

Forwaring: 목적지까지 가장 빨리 도달할수 있는 다음 포트 (위치)를 알려주는 표

Routing: 출발지부터 목적지까지 경로를 적어둔 표. 라우팅 알고리즘으로 경로를 파악해서, 빠른 구간을 알려주는 포워딩 표를 만들 수가 있다.

가장 큰 차이점은, decisions in local or global 이라고 볼 수 있다.

포워드는 내 위치에서 목적지를 향하는 가장 가까운 다음것만 알려주니 Local.

라우팅의 경우 여러 경로를 알고 있으니 (의도적으로 다른 경로를 알려줘서 로드를 줄일수도 있음)

Spanning Trees

loop을 없애서 안전한 경로를 만들었음. 하지만 이로 인해 바로 옆에 있는 경로도 선택을 못하는등의 낭비가 발생함. 즉 만들어진 경로에 대한 퀄리티를 측정할 방법이 없음

Routing

어느 경로로 일정 트래픽을 보냄으로써, 네트워크의 대역폭을 그 경로의 조건과 요구사항에 적응하며 형성.

라우팅은 이상적으로,

• 컨트롤러가 없으며, 모든 노드 (라우터)가 비슷하며 (같은 언어, 알고리즘 등등)
• 이웃과 소통을 하며 학습하고, 각종 링크/메세지 실패를 처리 해야한다.

라우팅에는 몇가지의 Expectiatons 들이 존재하는데

• Correctness - A 로부터 B에 패킷이 전달되어야 한다.
• Efficiency - Use available bandwidth and other resources (CPU, energy)
• Fairness - Dont ignore capable network elements (적절한 네트워크 요소에 공평해야 한다)
• Convergence - Recover fast from disturbances
• Scalability - Copes (대응) with large and complex networks

최선의 경로란 무엇인가?

• 최선을 정의하는것에 다양한 요소들이 존재하는데
  • 레이턴시 (distance delay), 대역폭, 코스트, 홉스 (forwarding delays)
• 고정된 위상을 사용할 경우, 링크 혼잡과 라우터 부담등을 전혀 고려하지 않는다

Shortest path routing

가장 비용이 낮은 라우팅을 말하며, 양 종단간의 route간에 소요된 비용중 가장 낮은것을 선택함. 물론 해당 비용은 정의에 따라 다르다 (홉수, 속도, 지연, 가격 등등)

Optimality Property: ABCDE 가 AE를 연결하는 가장 짧은 구간이라면, AB, CDE, BCD등의 sub 구간또한 가장 짧은 경로이다.

• Sink(source) Tree: 각 소스로부터 해당 node까지의 가장 가까운 경로들의 합.
  • E의 sink trees = FE, DE, BE, ABCE등
  • 물론 소스 트리의 경우 양방향을 고려하기도 해서 만약 비용이 비대칭적이라면 sink tree ≠ source tree.
• 어느 곳에서 시작을 하던, 결국 라우팅 결정은 목적지에 따라 결정된다. 어디서 시작되는지는 사실 중요하지 않음.
• 각 노드들은 해당 목적지까지의 가장 가까운 경로를 가진 다음 hop만 알고 있으면 됨 (포워딩 테이블)

Dijkstra’s algorithm

위상과 비용이 주어졌을때 각 소스에 대한 소스 트리를 만든다, 위에 명시된 Optimality property를 사용한다

https://namu.wiki/w/%EB%8B%A4%EC%9D%B5%EC%8A%A4%ED%8A%B8%EB%9D%BC%20%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98

1. 소스로 부터 시작해서 모든 소스들에게 반복적으로 탐색을 시도한다
2. Leverages optimality property - 부분 구간을 이용하여 더 긴 가장-짧은 구간을 만든다
3. 복잡한 네크워크에서는 스케일링 문제가 있다 - 한 부분이 바뀌면 다시 다 탐색해야함.
4. Complete Topology을 필요로 한다 (각각의 노드/소스 로부터)

Distance Vector Routing

위상을 모를때, 가중치가 음일때도 사용가능하지만, 다익스트라보다 시간 복잡도가 높다

노드들은:

• 이웃까지의 비용밖에 모른다, 오직 이웃과 대화한다
• 모든 노드는 같은 알고리즘을 사용한다, 노드와 링크들은 메세지를 잃거나 실패할수 있다.

모든 노드들은 모든 종착지에 관한 거리와 다음 노트를 저장하고 있다

1. 루트를 더하거나 삭제할때, 옆 이웃과 이야기가 안되면 업데이트 할때 서로 알려주면됨
2. 어느 특정 네트워크가 사라질때 구간의 비용이 무제한이 될 수 있음 - 이에 대해 따로 알고리즘이 필요함
   1. 만약 ABCD 에서 A가 사라지면, B는 C 에게 C는 B에게 A에 대해 서로 물어보게됨
      1. 왜냐면 A-B 로 이어져 있어도 C-A연결이 가능할수도 있으니까 (평소에는 그냥 최단거리만 알고 있음)
   2. 이를 해결하기 위해 Poison reverse or split horizon을 이용한다
      1. 내가 루트를 배운 노드에게는 내 노드를 광고하지 않음
      2. 몇몇 상황에서는 well scale 하지 않음.

Link State Routing

더 많은 계산을 필요하지만, 더 나은 모습을 보여줌. 기업네트워크에서 스케일이 좋다 (글로벌은 아님)

예로는 Open Shortest Path First (OSPF), IS-IS

다른 알고리즘과 비슷하게 다음과 같은 요소들을 가지고 있음

• 이웃과 이야기하며, 그들만의 비용만 알고 있고
• 위상을 모르며 (초반에), 노드/링크/메세지 실패를 처리할수 있다.

Simple Algorithms in 3 parts

1. Flood the network
   1. Broadcast incoming message to all outbound - 이를 link state packet (LSP)라 칭한다
      • 내가 받은 메세지를 모두에게 알려주는거.
      • 놓치면 ARQ 이용해서 다시 알려달라함
   2. 돌고돌아 자신에게 도착했을때 반복하지 않도록만 알고 있으면 됨 (보통 증가하는 넘버를 사용함)
2. Learn the topology
   1. LSP를 듣고, 위상을 파악함
3. Compute Tables with Dijkstra
   1. 아마 여태 받음 LSP들을 다 저장해서 각 노드에 개별적으로 계산하는듯
   2. 내부적으로 (스스로) 다익스트라를 실행함)
   3. 반복적이고, 많은 씨피유를 낭비하지만 효과적임
4. Repeat everytime whene there is a change.
   1. 만약 한 링크의 변화를 감지하면 업데이트된 LSP를 1번하고 3번을 모든 노드가 다시 함

• 다양한 실패들이 존재함 (flood, node flaps, seq# error 등등)
  • LSP ageing and timeouts 를 이용해서 처리한다.

Equal Cost Multiple Path

라우팅 프로토콜/알고리즘은 아니고 그냥 extension임

소스와 목적기까지의 경로를 여러가지를 가지고 있음으로써, 로드 밸런스, capacity increase와 같은 성능 향상과 Greater redundancy (불필요한 반복) 를 가져온다.

이를 위해 Detect 와 foward traffic along with paths 가 요구된다

Detection:

• 같은 비용의 여러가지 경로가 존재 한다면 모두를 저장해둔다.
  • ABE, ABCE, ABCDE 모두 비용 8
  • Not a tree, but a directed acyclic grapd

Forward: Detection을 통해 이제 forward table 는 각 목적지에 여러 인터페이스를 가진다

• 각 패킷에게 다른 경로를 (무작위로) 제공한다.
  • 이로 인해 로드밸런싱은 좋으나, jitter (패킷 딜레이 variation)은 안좋다
    • 왜냐면 다른 경로를 통하니 서로 PDV 가 다르지
• 관계에 따라 경로를 제공한다
  • 소스와 목적지의 아이피 주소를 이용한다. 같은 비용, 지속적인 성능을 제공한다
    • 아이피 주소를 이용해서 이 아이피 주소는 이 경로만 이용하는거
• 흐름에 따라 제공
  • Use of flow identifiers (IPv6)

이러한 방법들은 불균형적이지만 좀더 예상 가능해 진다.

Hierarchical Routing

• 스케일링 문제가 존재한다
  • 라우팅 테이블, 계산, 포워딩 테이블의 크기가 점점 증가하기 때문이다
• 네트워크 aggregation -
  • LAN prefix 가 이미 존재하기에 그것을 이용한다
    • 한 서브넷안의 모든 호스트를 광고할 필요없다, 나 (라우터) 에게 결국 와야 하니까
  • 한 서브넷의 집합을 큰 서브넷처럼 다룬다 - 모든 서브넷들이 붙어 있는건 아니다

Routing to a region

• 장점: 노드와 서브넷을 합쳐서 지역으로 간주한다.
  • 이로 인해 그 안의 복잡함을 감추고, 테이블의 길이를 짧게 한다
  • 또한 통신과 계산등을 줄일수 있다.
  • 지역간을 담당하는 라우터를 지정하고, 각 지역마다 어떤 방식을 사용할지 결정도 가능하다.
    • 즉 A는 B 쪽 라우터를 가려면 꼭 이 라우터를 통과해야 하는 담당 라우터를 말하는것
• 단점:
  • 덜 효율적인 경로가 만들어질수 있다.

Policy Routing

• 다양한 정치적인 기준점이 존재한다; 돈 정치, 보안, 종교

14. Routing in Internet - 인터넷에서의 라우팅

• 가장 짧은 경로는 결국 지역적 우선순위, ISP는 단지 부담을 최대한 줄이고 싶을뿐
• Hot Potato Routing 이라고 한다
  • 최단 경로가 아닌, 어느정도 짧은 경로 이용
  • 비대칭적인 경로, 오고가는길이 다를수 있음
  • 계층은 좋은 비지니스 이유로 수립되지 않음

Common Policy

1. Transiting: ISP A 가 너의 인터넷 연결을 관리함
2. Peering: ISP A가 너에게 인터넷 트래픽을 주고 받고 제공하지만, A가 인터넷에 연결된게 아닌 ISP B로 부터 인터넷을 받아오는 형식

Border Gateway Protocol (BGP)

다른 ISP간의 트래픽 전송을 방지하고 자신의 네트워크를 통해서는 트래픽 라우팅을 원하는 정책

오늘날 가장 흔한 정책이다

키 컨셉트:

1. Autonomous System (AS) 즉 자치 시스템안에서의 노드들을 통합
   1. 이로 인해 확장성 문제를 해결화 한다.
2. Border Router (Gateway) which run BGP 를 확정한다
   1. 외부 (네트워크) 와 지역 (자치 시스템) 사이를 담당한다.
   2. 이 게이트 웨이가 다른 라우터에게 자신이 담당하는 경로를 알릴지 말지 결정 가능하다
      1. 이 라우터에게 정보를 받지 못하면 이 네트워크 이용 불가능 하다 (뭐있는지 모르니까)
      2. 혹은 몇몇 경로만 필터링해서 알려줄수도 있다.
   3. 또한 이 게이트웨이는 다른 라우터로 부터 도착한 메세지의 목적지를 보고, 내가 제공하는 경로중 하나이면 다음 홉으로 패스해준다. (이 조건은 가격, 친구요청인지, 안전한지 등등 많다)
3. 외부와 내부의 라우팅 프로토콜의 단절화
   1. Intradomain
      1. 하나의 관리자가 제어하므로 정책 결정 무필요
      2. 성능에 초점
   2. interdomain
      1. 각 네트워크 관리자 끼리 정책을 교환한다
      2. 정책에 초점 - 최소 비용이 더 중요하기 때문

BGP는 LS 보다는 DV에 해당한다 (DV 보단 Path vector에 더 가깝다). 루프의 존재를 감지와 함께 삭제할 수 있다.

위의 경고 광고는 다음을 포함한다

• IP Prefix, next hop
• Path: list of AS’s to transit
  • 이로 인해 루프의 존재 감지및 삭제를 가능하게 한다
  • 거리 indication 은 없다.

정책 Implementation

• BGP 로 누구한테 “광고”를 할지 설정할 수 있다
• Border Routers 들은 가능한 경로들을 광고 하는데 (얘네가 담당하니까 다른 Inter domain 연결을)
  • 얘네가 사용 가능한 (허락해준) AS 에게만
  • 혹은 얘네가 허락해주는 AS 에게만
  • 혹은 알려주되 다른 경로들 (빠르거나 느리거나) 을 AS에 차별해서 나눠준다 (AS간 금전거래 이유등등)

와 같은 다양한 이유와 목적을 가지고 경로들을 알려줄 수 있다.

• 또한 Border Router 들은 다양한 announcements 들을 주위로부터 받는데 자신이 사용하고 싶은 광고만 골라서 네트워크 안으로 전파할 수 있다 (예를 들어 같은 목적지에 갈 수 있는데 싼 비용의 SA 광고만 전파한다던가 등등)

보통 peer 관계의 경우

[B, (AS3), borderRouter 3a] → B는 AS3 의 3a 라우터를 통해 도착할수 있습니다 알려주는것

transit의 경우

[B, (AS1, AS3), router 1b] → B는 AS1 을 통해 AS3 로 가서 도착할 수 있는데, 먼저 AS1의 1b 라우터를 통해 오십시오 같은것

결국 위의 A 손님은 B 로 갈수 있는 방법이 두가지인것. 보통 peering 이 무료다.

Monitoring

Network Feedback

• ECN (Explicit Congestion Notification): Router set up ECN flag
• ICMP (Internet Control Management Protocols): ping/traceroute 등으로 사용
• TCP ACK: sequence number 로 알아차리는거

SNMP

Simple Network Management Protocol (SNMP)

We want to….

• Reach everywhere: 모든 타입, 종료의 기기들 (스위치, 라우터, ap, IoT 등등)
• Lightweight: 기기의 성능에 영향 가지 않도록 (no interference on device)
  • No rates, no calculation, no history
  • No absolute clock: 정해진 클록이 존재하지 않음 (즉 다양한 클록 스피드로 통화가능)
  • 단지 Counters/gauage, Time since start-up, strings/identifiers 만 존재
  • 시간은 1/100 sec 단위이다
  • command/control 은 변수 셋팅을 통해 이루어진다
• Operate when under stress: 부하가 걸린 상태에서도 작동 가능하게
  • 뭐가 문제인지 알아내고 고칠수 있도록 도움을 주기위해서
• Scale to large num of device: 글로벌 네이밍, delegated, 제조사-독립적, 추가적
  • 즉 누가 만들고 이런거를 떠나서 다양하게 많은 수의 기기들을 포함할수 있도록
• Provide both queries/response and command/control: 질문/답변, 명령/조종 모두 가능하게
• security and upgrade later

말 그대로 간단한 네트워크 조절 프로토콜로, 네트워크에 수많이 존재하는 모든 기기들 (무슨 타입 종류건 상관없이) 에 대해 문제가 생기면 고칠수 있고, 해당 기기와 교류 할 수 있는 (질문답변…) 것을 제공하는 것.

이는 곧 해당 네트워크 기기에 문제가 생기면 경로를 탐색할 필요 없이 걔만 고치면됨.

따라서 부담을 줄이기 위해 UDP 161 (서버), 162 (에이전트) 포트를 사용한다.

여기서 에이전트는 (서버) 클라이언트는 (매니저) 이다.

SNMP

• 어플리케이션 프레임워크
• 네트워크 리소스의 관리 및 모니터링 담당
• SNMP 구성요소로는 다음과 같다
  • SNMP agents: 각 기기에 존재하는 소프트웨어
    • 설정및 데이터베이스 상태 관리
    • Proxies: 혹은 non-SNMP (IoT 등등 얘를 거쳐야만 그 기기랑 대화 가능) 기기와 대화 가능한 프록시 역할해주는 agent
      • Proxy agent 와 Proxied Agent가 존재한다.
  • SNMP managers: agent와 대화하는 어플리케이션
    • 해당 에이전트의 데이터베이스를 쿼리 혹은 수정하는 역할
    • 또한 네트워크 장치의 이벤트를 인식함 (에이전트가 전송함)
    • Network management system 의 일부이다
  • Management Information Bases (MIB)
    • 다양한 데이터 베이스 구조가 존재함
    • Structure of management Information (SMI) 는 MIB에 존재하는 관련된 오브젝트를 정의함
    • 즉 관리 장치에 대한 정보가 집합되어 있는 데이터베이스
  • SNMP protocol
    • 여러 버전 존재함 1, 2, 3

SNMP Messages

• SNMP/UDP is connectionless
  • request ID 를 이용하여 세션을 유지한다
• SNMP messages use “protocol data units” - PDUs
  • 다양한 버전의 SNMP는 같은 PDU를 다른 메세지로 사용한다 (그래서 지금 문제되고 있음)
  • 또한 각 다양한 메세지 form은 이 PDU의 전체 맥락에서 조금씩 바꿔서 사용하는것

Trap : 에이전트가 무슨일이 있다고 (이벤트) 매니저에게 알리는것 (비동기적 - 일방적으로 알리는것)

• 링크 다운/업, 스타트 콜드/웜 (급작스러운 재시작 혹은 예정된 재시작)
• 인증실패, egpNeighbourLoss (링크는 켜졌는데 이웃이 사라짐)

과 같은 6가지 기본 상태와 벤더에 따른 여러 trap 상태가 존재한다 2^32 개수까지 존재 가능

SNMP Community - 어디 소속인지

• SNMP1 의 경우
  • 특정 변수 셋트에 대해 특정한 액세스를 정의함
  • read-write, read only, none 등의 세가지 타입이 있음
• 각각의 SNMP 는 community name 이
  • 패스워드 같고, 암호화 되어 있지 않음
  • 이게 무슨말이냐면 read-only: Public, read-write: Private 가 비밀번호임 ㅋㅋㅋㅋ
    • 따라서 보안적으로 하나하나 새로 설정해 주지 않으면 위가 기본 비밀번호
• 에이전트가 특정 IP 주소를 저장해서 해당 아이피의 매니저만 데이터베이스 건드릴수 있도록 하는것도 가능

SNMP Versions

• v2c
  • 벌크 기능 추가, 매니저간 대화 기능 추가, TCP 기능 추가, 64 비트 카운터 추가
• v3
  • 보안 추가 (v2c 의 기능은 없음)

보통 다들 v1,2,3 모두 지원함

SNMP Security

• v1 - community string 을 인증 방법으로 이용함 (아까 그 public, private) - 암호화 전무
• v2 - 위 문제 고쳤어야 하는데 안고침 ㅋㅋ
• v3
  • Integrity - 패킷이 tampered 되지 않음을 분명히 함
  • authentication - 정당한 소스로부터 해당 메세지가 왔음을 분명히 함
  • privacy - 메세지가 읽히지 않음을 분명히 함
  • 다향한 보안 단계를 가지고 있으며, 단계에 따라 접근 권한이 다르다
    • noAuthNoPriv: 유저네임 매칭을 통한 인증 방법
    • authNoPriv: 메세지 digest를 이용한 인증 방법
    • authPriv: message digest 를 통한 인증과 암호화 사용

MIB 안에 값들이 저장되어 있는데, SMI 를 통해 정보가 수집된다 (통계 자료 등등)

예를 들어 값들이 어느 디렉토리 안에 저장되면, 해당 디렉토리까지 가는데 SMI 을 통해서 지나간다. 이 지나가는 와중에 해당 정보들을 structure 하게 수집해서, 몇개의 패킷이 지나갔는지, 지금 전송율이 어떤지 등등을 모집하는것이 바로 Structure for Management Information (SMI) 이다.

물론 에이전트가 직접 계산하는게 아니라, 단지 자료를 모음으로써 위의 계산들을 가능하게 해주는 형식

Counter / Gauages

• 위 두가지가 현재를 가장 잘 알려줌
  • Counter: 현 인터페이스에 존재하는 패킷들 (can wrap)
  • Gauge: 메모리/디스크 공간 (0부터 맥시멈까지)
• 에이전트는, 다시 말하지만, history를 가지지 않으며 계산도 하지 않음
  • 단지 켜진 순간부터 얼마나 시간이 지났나만 알고 있음
• 따라서 매니저는 계속해서 물어보면 다음과 같은 가정들을 세워야함
  • Counter 가 바뀌지 않았다 (패킷 수가 똑같다) → 이전과 같은 상태
  • Gauge가 바뀌지 않았다 → 이전과 같을수도 다를수도 있다 (메모리/디스크 소비량은 같은데 값은 바뀔수 있으니까)
  • MIB 디자이너는 해당 정보를 위해 여러 필드/타입이 필요 할 수 있다 (즉 어느 정보를 유추하기 위해서는 여러가지 필드들을 참조해야 할 수 있다)

ASN

데이터들은 ASN 이라는 Abstract Syntax Notation One 규격에 따라서 저장된다

string 예시로는

• Access: Read only, read-write, write-only, not-accessible
• Status: mandatory, current, optional, obsolete

이 존재한다

가장 중요한것은 Object Identifier 이다

• 정보 오브젝트와 레퍼런스를 알려주는 identifier로 international 한 수준에서 관리된다.
• globally unique → MIB에서 무조건 unique 함

OID (Object Identifier)

• 나무 계층적이다 (DNS처럼) - 각 OID 는 나무의 노드에 해당한다
  • 1.3.6.1.2.1 의 경우 루트에서부터 각 계층의 OID를 타고 내려오는것
  • 제조사는 각자 이 OID에 특정한 object를 만들수 있음

즉 MIB 1.3.6.1.2.1.2 의 디렉토리에 ifNumber 라는 오브젝트를 만드는것. 해당 오브젝트는 Integer를 (읽기만 가능하며) 값으로 가지며 필수적인 오브젝트.

OID 의 필요성?

OID 가 왜 필요하느냐 하면

• gloabl uniqueness 와 extensibility를 가지고 있다
• human-readable-names를 나무-위치-identifier 형식으로 가지고 있다
• ASN1 은 테이블 (사람이 쉽게 읽을수 있는) 을 제공하지 않는데, 사람이 관리상 필요함

Table and GetNext

Get-Next : 예를 들어 IP 관련 데이터를 받으려면, 하나 받고 그다음꺼로 계속 요청해야함

즉 같은 형식의 정보를 얻으려면 GetNext를 계속 반복해야 하는거 → 당연히 GetNext를 반복하면 트래픽도 생기고, 관리하기도 힘들다

버전2 에서 이를 위한 벌크 형식이 등장했는데 다음과 같이 작동한다

1. Get bulkt(“interface”) - every row every column 을 넘기는 형식
2. ONLY ONE UDP 로만 반응한다. 만약 이 64kb의 UDP 제한을 넘기면 tooBig 이라는 오류가 발생한다.
   1. 즉 트래픽 최소화를 위해 한 UDP로 교환이 가능하도록 만들어둔것.

SNMP를 내 도메인 이후로 넓히는것은 현명하지 않은 선택이다.

1. 에이전트들을 바깥에 보여주는것은 옳지 않으며 (보안상인듯) - 특히 보안이 약한 1,2
2. 이로 인해 많은 트래픽이 생성되고
3. 남들이 해당 네트워크를 쉽게 스캔, 맵핑할수 있기 때문.

이로 인해 타 도메인과의 확장은 사람간의 문제가 된다.

Q: On congestion, where does that actually happen on a network path?

A: 어느 특정 아웃바운드 연결/경료에 대해 너무 많은 트래픽이 올시에 라우터의 버퍼에서 발생함

• 특정 아웃바운드 연결/경로가 중요하다. 각각의 연결/경로는 다른 버퍼를 가질수 있으니까.
• 라우터 버퍼가 가득참 → 패킷이 드롭됨 → 손실 발생
• 라우터 버퍼가 거의 가득참 → 패킷이 보내지는데 시간 걸림 → 지연 발생

Q: What’s the difference between ‘throughput’ and ‘goodput’?

A:

• throughput은 통과하는 데이터의 볼륨 (크기)를 말한다 (그게 무슨 데이터간에).
• Goodput은 통과하는 “새로운” 데이터의 볼륨을 칭한다 (이게 어플리케이션에서 말하는 “effective transmission rate” 과 관계되어 있음). 즉 재전송이 아닌 새로운 데이터의 볼륨.

Q: Why do we get a collapse in goodput as we approach congestion?

A: 혼잡해질수록 새로운 데이터가 통과하는 볼륨은 줄어들고 대신 retransmission 과 이에 대한 requests만 늘어날테니까.

Q: Why does TCP traffic (often) have a sawtooth pattern?

A: 네트워크를 정찰 (probe) 하면서 혼잡을 일으키지 않을떄 까지 점점 증가하다가, 혼잡이 발생하자마자 바로 줄여버리니까

• Additive Increase, Multiplicative Decrease (AIMD)

Q: How can we detect congestion? (3 ways, at least)

A:

• 패킷 손실 증가: 명확하게 혼잡 감지, 대신 혼잡이 생긴후에 감지
• 패킷 지연 증가: 혼잡이 생김을 예상 (추론), 혼잡을 미리 감지함
• ECN: 혼잡을 감지 (라우터가 알랴줌), 대신 라우터와 호스트간에 협조 필요
  • IP header에 플래그를 설정한다.

Q: How does Selective Acknowledgement (SACK) greatly help TCP performance?

A:

• 송신자에게 수신가자 무엇을 받았는지 정확하게 알려줌으로써 놓친 부분만 다시 보내게 되니 보내는 양이 줄어들고 성능에 도움이됨

Q: What’s the difference between ‘fairness’ and ‘efficiency’ in networking terms?

A: 공평성은 네트워크 접근에 공평하게 (비슷한 송신율) 처리되는지. 효율성은 전체적인 네트워크를 보면서 가능한 최대한 성능을 끌어 올리고 있는지

Q: TCP has (at least) 3 types of “windows” for managing the transmission of segments (over
packets). Explain their key roles: SendWindow, ReceiveWindow, and CongestionWindow

A:

1. SendWindow: 네트워크 효율성을 최대한 높이기 위해서
2. RecvWindow: 송수신자 간의 성능 밸런싱을 위해서 (수신자가 송신자보다 빠르면 문제가 발생함)
3. CongestionWindow: 송수신자간의 네트워크의 capacity 를 (거의 즉각적으로) 계산해서 흐름간의 공평성을 보장함. 혼잡 윈도우는 그냥 전송가능한 버퍼크기라고 생각하면 되는데 송신자는 최대 자신의 혼잡윈도우 크기만큼 트래픽을 전송가능하다. 이 혼잡윈도우는 네트워크의 혼잡도에 따라 커지기도하고 작아지기도 한다.

Q: Can you explain the difference between unicast routing, broadcast routing and multicast routing? i.e. what are they trying to achieve?

A:

• Unicast: 호스트간의 전달을 기반으로 다른 호스트에 부하는 주지 않는다. 다만 동일한 정보를 많은 호스트에게 전달할시에는 비효율적임
• Broadcast: 단일 호스트가 세그먼트의 모든 호스트를 대상으로 전달. 여기서 세그먼트는 브로드캐스트 도메인, 즉 자신의 네트워크를 지칭함
• Multicast: 흥미 있는 구독자와 그룹멤버들에게 예약된 주소를 통해 수신 (즉 유니캐스트 같은 브로드캐스트) 224/8

Q: Why does routing tackle fixed parameters about links, and ignore dynamic things like
congestion and load?

A: 라우팅 알고리즘은 각각의 모든 라우터들이 포워딩 테이블을 만드는데 사용된다 (시간과 에너지) 이러한 알고리즘들은 congestion/load 와 같은 변화들에 빠르게 반응하지 못하며, 할 생각도 없다.

• 라우팅 알고리즘에서 가장 중요한것은, 해당 링크의 존재 유무 (크게는 위상)와 비용이다.
• 혼잡과 로드는 알고리즘의 부가적인 요소에 불과함 (먼저 라우팅 테이블이 있어야 혼잡이던 뭐던 해결책을 제시할수 있으니까)

Q: What is a sink tree, and how does it differ from a source tree?

A:

• sink tree = soure tree일때는 양 방향의 비용이 같을때이다. 즉 A부터 B가 3, B 부터 A가 2라면 싱크 트리와 소스트리는 다르다.
• 싱크트리: A에 대한 shortest paths의 조합 (모든 노드로부터) 즉 A로 싱크
• 소스트리: A로 부터 shortest paths의 조합 (모든 노드에 대해) 즉 A가 소스

Q: Can you explain the path optimality property?

A: 어느 최단 경로의 부분 경로는 그 부분 경로간의 최단경로임

Q: What’s the downside of using Dijkstra’s algorithm? Why is Distance-Vector (Bellman-
Ford) better?

A:

• 다익스트라의 경우 전체 위상을 미리 알아야 하고, 모든 노드들을 알아야 함
• DV는 음의 가중치일때도 사용 가능하며, 위상을 몰라도 되지만 시간 복잡도가 더 높음
  • Distributed algorithm
• Likn-satet: 링크 스테이트 라우터를 이용하여 서로 네트워크 위상을 배울수 있도록 메세지를 교환함.

Q: What’s the benefit of regional route aggregation? What’s the downside?

A:

• 장점은 네트워크의 포워딩/라우팅 테이블이 유의미하게 짧아지고 라우터들의 테이블 업데이트 유지에 관한 processing load를 줄여줌. (테이블이 짧으니 유지보수 할것도 적지)
• 단점은 해당 경로가 최단 경로가 아닐수 있음

Q: Why do we use different routing algorithms internally versus globally?

A:

• 내부적으로 (지역) 정확한 지식을 가지고, 짧은 네트워크 반경을 가짐. 따라서 DV나 다익스트라, link-state 모두 가능하고 (다양한 라우팅 알고리즘 가능), reasonable 한 시간내에 완료 가능함.
• 외부 네트워크에 대해서 불완전한 지식을 가지고 있기에, 그냥 바깥 지역으로 던지고 걔네가 알아서 해결하게 두는게 편함.

Q: What is the difference between a transit and a peering arrangement?

A: transit: 나를 통해 다른 네트워크 갈 수 있음 (유료). Peering: 내 네트워크 내의 기기에 접근 할 수 있음 (대부분 공짜).

Q_1: What causes the ‘latency’ on the left?

A_1: sender/receiver transmission 딜레이로 피할수 없는 딜레이 이다.

Q_2: What causes the long tail at the far right?

A_2: 도착하기 까지 여러 구간에서 다양한 이유로 멈춰진 패킷들의 도착

Q_3: What would cause jitter to become very large?

A_3: 지터는 다양한 넓이의/종류의 딜레이를 나타낸다. 아마도 이와 같은 경우는 중간에 경로가 다양하게 바뀌었거나, 해당 경로의 라우터들의 load가 갑자기 바빠지거나 한듯하다

Q: Why is packet 4 not able to be played out, since it was received? How could we fix that? What problem does that cause?

A: 수신 버퍼의 길이가 패킷 4를 수신하기에 너무 짧았음. 이를 고치기 위해 버퍼의 길이를 더 늘릴수 있지만, 그렇게 하면 송신과 플레이 시간의 지연이 더 커질것임. 따라서 실시간이라 부르기 애매해진다 (내가 말하고 몇초뒤에 상대방이 답한다던가 하는것).

Q: Why is retransmission (except in multicast) generally a bad idea? Why is it ok in multicast?

A: 잃어버린 패킷을 감지하고, 재요청하고 (그 잃어버린 패킷을 아직 가지고 있길 희망하면서), 패킷을 받는과정이 너무 오래걸리기 때문. 물론 재요청해서 바로 받는다는 보장도 없다. 멀티캐스트에서는 retransmission 해주는 위치가 가까울수 있어서 지연이 줄어들기 떄문.

Q: Why are the performance problems reduced in streaming applications?

A: 문제는 여전히 존재하나, 이는 단방향 트래픽이기 때문에 딜레이를 알아차리지 못한다 (화상 통화가 아닌 트위치 같은거 말하는거). 이 뜻은 내가 받은 버퍼의 크기를 키워서 안정적인 (reliable) 프토토콜을 사용 가능하다는것. → 내가 트위치 볼때 안끊기기만 하면 되니까 이에 맞춰 버퍼만 키우면됨

Q: What are the main network and device issues for IoT? Why is it different to other devices connecting to the internet?

A: Scale, Power, Network, Timeliness, Reliability → 해당 자료 읽어볼것.

Q: As an application model, how is PubSub different to Client/Server? Why is it better suited to large-scale IoT applications?

A: 클라이언트와 서버는 1:1 관계를 가진다 반면에 PubSub은 데이터 진원지 (소스)와 publishing 하는것이 나뉘어져 있기 때문에 서버/브로커를 통해 구독자들이 정보를 얻을수 있다. 또한 확장성과 관련해서 n 개의 생산자와 m의 소비자들이 있다면, n*m 대신 n+m의 직접적인 관계를 유지 할 수 있다 (중간에 브로커 하나). 또한 이러한 관계는 오직 해당 토픽에 관심있는 구독자들에게만 정보를 push 하기 때문에 reducing load for producers and brokers.

Q: Why are MQTT packets so compact and simple? (compared to HTTP say)

A: 성능과 부하를 위해서 이다. 짧은 메세지는 대역폭을 거의 소모하지 않고 간단함은 패킷 구성에 관한 CPU 소모량을 줄일수 있다.

Q: Why does MQTT offer multiple levels of QoS (quality of service)? Why is there separate, potentially different, QoS on both sides of the broker (producer->broker, broker->consumer)?

A: 상황에 따라 해당 메세지가 반드시 ensure 해야 할지, 혹은 가끔 업데이트로 충분한지, 혹은 메세지를 놓치더라도 다음까지 기다릴수 있는지 등 요구조건이 다르기 때문이다. 해당 소비자가 그 정보에 대한 중요도가 다르기 때문에, 중요하게 여기는 소비자는 높은 QoS를 이용할것이고 아니면 낮은 레벨을 사용할 것이다. 이로 인하여 데이터 소모량에 대한 유연성을 가질수 있다 (QoS 레벨에 따라 데이터 필요량이 다르니까 - 커뮤니케이션 횟수가 다름)

• QoS 0 을 선호하는 사람들은 굳이 복잡한 QoS 2 안 써도 되니까.

Q: In what circumstances is it useful for a server to ‘retain’ an MQTT-published message?

A: 소스가 가끔 메세지를 주던지, 소비자가 언제던지 들어올수 있던지, 혹은 비안정적으로 연결되어 있던지 할때 좋음. 서버에 리테인 함으로써 위와 같은 상황에 현재 which state (메세지) 가 있는지 빠르게 배울수 있음. 즉 서버가 정보를 가지고 있으면 소비자가 재부팅하고 (그 사이에 정보를 못받았던, 정보가 초기화 되서 아무것도 모른다던지) 다시 들어와도 빠르게 “응 지금 메세지 이 상태임” 하고 알려줄수 있는거.

Q: What is the ‘root’ of the Domain Name System? i.e. what is at the very top?

A: “,” is the root of the DNS. It is to refer the root DNS server

Let’s look at some Fully Qualified Domain Names (FQDN) with different Top Level Domains (TLD). Consider: www.anu.edu.au. and www.gov.au

Q: Which part is the ‘genericTLD’ (gTLD)?

A: Edu, gov.

Q: Which part is the ‘countrycodeTLD’ (ccTLD)?

A: au 다만 미국의 경우 us 를 사용하지 않음.

Q: Which part is the hostname?

A: www 가 이에 해당한다. DNS에서 해당 주소 (www.anu.edu.au) 의 A가 이 호스트 주소에 해당된다.

호스트 네임은 종단 기기에 지정된 이름 (DNS를 통해 식별)

도메인 네임은 네트워크에 지정된 이름 (네트워크에 연결되야함)

Q: In the case of cbs.anu.edu.au is the ‘cbs’ a hostname or a domain name, or both? How can you tell the difference? What’s the benefit/downsides of this approach?

A:

• 모두 가능하다. (host and domain)
• www.cbs.anu.edu.au 혹은 mail.cbs.anu.edu.au 와 같은 호스트네임을 가질수도 있다 (www, mail)
• 아니면 cbs.anu.edu.au 라는 cbs 호스트 네임을 anu.edu.au 라는 도메인에 가질수 있을수도 있음
• 어차피 DNS를 통해 확인후 전달 하기 때문에 길다면 줄일 수도 있는거. 대신 커넥션을 만들기전에 확인해야 한다.

만약 종단의 이름이 a 이고 도메인이 x 라면

해당 종단에 대한 주소는 a.x 가 되는 형식

Q: In HTTP, how does the application handle the ‘session’ and ‘presentation’ layers?

A: 세션은 쿠키로 관리된다. 또한 URL-Referenced tokens 들로 관리 되기도 하는데 이때는 쿼리 필드의 어느 부분을 공유하는 식을 이용한다.

• 세션 기반의 문제점은 이 기록을 서버에 저장을 해야 하는데, 이로 인해 확장성이 좋지 않음
  • 세션을 유지 할 수 록 더 많은 트래픽을 감당하기 위해 프로세서, 서버등을 추가해야함
  • 이 과정이 매우 복잡하다
• 토큰의 경우 상태 유지를 하지 않아 (stateless) 고로 확장성이 좋다
  • 클라이언트 쪽에서 정보를 저장하기 때문에 서버 확장에 용이하다.
  • 또한 클라이언트가 서버에게 쿠키를 전달하지 않음으로 쿠키로 인한 보안 취약점이 사라짐 (대신 토큰 보안 취약점 존재)

Q: TCP 192.168.1.2:53398 150.203.56.47:80 CLOSE_WAIT

A: 소켓이 현재 닫혀진 상태이나, 웹 서버로부터 마지막 ACK를 받기를 기다리는 상태

Q: Packets with a source IP address of 0.0.0.0 is used (by DHCP) to signify what? What does the address mean to the Operating System? Why do we use it that way?

A: 이는 해당 호스트가 현재 아이피 주소를 모르고 있은 상태이고, 이로 인하여 해당 호스트와 연락하기 위해서는 브로드캐스트를 이용 할 수 밖에 없다. 운영체제에서 0.0.0.0 은 “모든 인터페이스” 를 뜻하며 모든 인터페이스들에게 보내지고 모든 인터페이스는 이 메세지를 듣는다.

Q: Why does DHCP have both discover/offer AND request/acknowledge? Why not just
request/acknowledge?

A: DHCP의 아이피 주소 할당은 임시 (lease)이며 확인되어야 하기 때문이다. 또한 만약 여러기기가 동시에 같은 아이피 주소를 요청할 경우를 대비해야 하기 때문이다. 따라서 서버와 클라이언트는 해당 아이피가 고유하다는것을 알기위한 확인 절차가 필요하다.

• Server Discovery
• IP lease offer
• IP Request
• IP lease ACK

Q: Give some examples where and why a single IP address may be used by multiple (DNS)
names? What about examples where a single name may resolve to multiple
addresses?

A: 예를 들어 같은 아이피 주소를 가지고 있는 웹서버와 메일 서버 같은 다른 서비스를 제공하는 경우. 이는 결국 일어날 서비스의 이동에 대한 유연성을 준다. 한 이름에 대한 여러가지 주소를 가지는 경우는 옵션과 같이 사용되는데 첫번째가 사용 불가하면 두번째가 사용된다던가, 혹은 이로 인해 로드 밸런싱도 가능하다.

Q: In DNS, how are Zones and Domains different?

A: 도메인의 경우 DNS 의 일정 부분을 이야기한다. 예를 들어 anu.edu.au 의 경우 도메인이고 (au, edu, anu 순으로 내려온다), 이 이하의 다양한 부서와 서버들과 같은 여러가지를 묶어서 zone 이라고 표한다.

Q: Why are DNS delegations legally important?

A: 도메인 네임은 보통 그 해당 entity의 법적 이름과 연결된다. 즉 구글이라는 사업체가 있는데 이를 모방해서 google.com 등을 사용한다면? 이는 곧 사기와 trademark infringement 와 같은 법을 어기는것.

Q: What’s the difference (and for/against) using Iterative or Recursive DNS queries?

A: Interative 는 내 스스로가 정보를 받고 다음에 물어보고 받고 물어보고 하는형식 Recursive는 네임서버에게 물어보면 걔가 알아서 물어물어 정보 가져다 주는것. 당연히 Recursive가 편하지만 더 느림.