DO MY BEST

인터넷 구조에 대해 살펴보면 네트워크들에 네트워크이다.

access ISPs를 통해 end systems(단말, host)를 연결 할 수 있다.    *access ISPs에는 reesidential, company, university ISPs가 있다.

이제 access ISPs에 end system을 연결했으면 access ISPs들을 상호 연결을 해야한다. 그렇게 해야지만 서로다른 access ISPs에 있는 어느 두개의 호스트들이라도 각각에 패킷을 전송할 수 있게된다. 그래서 묶어줘야 한다. 그렇게 되면 네트워크가 복잡한 형태를 띄게 된다. 그래서 네트워크에 네트워크 발전은 경제 상황이라든가 국가정책에 의해서 개선이 된다.

계속 인터넷 구조를 살펴보자 (다음으로)

첫번째로 각 엑세스 아이에스피를 나머지 엑세스 아이에스피에게 전부 다 연결하는 방법이다.

규모를 키웠다 줄였다 하는게 원활하지가 않다. 왜냐하면 O(N^2)의 연결이 필요로 하여 많은 연결이 필요하기 때문이다. 게다가 access ISPs 하나가 추가되면 또 다 연결해야하기 때문이다.

각 엑세스 아이에스피를 하나의 글로벌 ISP에 access net을 연결해주는 것이다. 그러면 원활하게 묶을 수가 있다. 

문제는 Customer ISP와 provide ISP간의 경제적 동의가 있어야 하는점이다.

만약 하나의 글로벌 아이에스피가 독립적으로 비지니스를 운영하면 금방 경쟁자들이 발생하게 된다. 그러면 이러한 경쟁자들을 또 묶어줘야 한다. 그렇게 되면 글로벌 아이에스피 간에 peering link를 만들던가 아니면 internet exchange point를 제3의 조직이 만들어가지고 각각의 ISP들이 연결 가능한 기기들을 삽입해 각각을 연결해야한다.

각 지역별로 묶어 글로벌 아이에스피로 뿌려주는 것도 있다.

그리고 자기 자신의 네트워크를 운영하는 content provide network 같은것들도 운영되고있다.

인터넷 구조를 정리해보면 이러한 모양이 된다.

Tier 1 ISP는 글로벌 아이에스피가 표현되고 구글로 표현된 것이 content provider network를 표현된다. 그다음에 IXP는 Internet Exchange Point라고 해서 제3의 사업자 또는 공공기관같은곳에서 서로다른 ISP를 연결할 수 있도록 장비를 갖추고 회선을 끌어다가 연결해주는 곳이다.

그래서 인터넷은 작은 숫자의 잘 연결된 커다란 네트워크를 중심으로 해서 연결되는데 tier-1은 commercial ISP가 되겠다. 우리나라로 치면 skt, kt LG 이런 사업자들이다.

Content provider network는 aws같은 곳이다.

[페킷스위칭과 서킷스위칭의 비교]

서킷스위칭에 비해 패킷스위칭이 더 많은 사용자가 네트워크를 사용하도록 허용할 수 있는 방식이다.

예를들어 link capacity가 1Mbps이다. 그리고 각 사용자가 active 일때 즉 전송할 패킷이 있고 네트워크를 사용하고자 할 때 100kbps의 속도가 필요하다. 그런데 항상 active상태가 아니라 10%의 시간만 active하고 나머지 90%의 시간은 idle 즉 사용하지 않은 시간이다. 

각 사용자가 100kbps의 속도가 필요하기 때문에 서킷 스위칭을 사용하는 경우에는 100kbps * 10하면 1mbps가 나온다. 그래서 서킷스위칭 방식에서는 할당받은 bandwidth를 배타적으로 사용하고 보장을 해줘야 하기 때문에 10명 초과의 사용자를 받을수가 없다.

그에비해서 패킷스위칭 방식에서 만약에 35명의 사용자를 수용했다고 가정하자. 35명 전부 다 이 링크를 사용하려고 하면은 사용할수가 없으니 몇명까지 이 링크를 사용해도 무리가 없을까를 계산해 보니 10명 까지이다. 그래서 35명의 사용자를 받을 때 동시 10명을 초과해서 active상태가 되는 확률은 얼마나 될까를 계산해봤더니 0.0004보다 작은 확률이다. 그러므로 충분히 35명을 수용해도 문제가 없다. 그래서 패킷스위칭방식이 서킷스위칭 방식보다 더많은 사용자를 수용 가능하다. 

그러면 0.0004의 값을 어떻게 나왔을까?

10명 이하로 active인거는 상관없고 초과하는 확률을 구하는거니깐 11명이 동시에 active한거를 구해야한다. 사용자 하나가 active할 확률은 1/10이다. 그다음 idle한 상태는 9/10이고,

그래서 사용자 11명이 active이고 나머지는 아닌 확률은 {(0.1)^11} * {(0.1)^24} 이다. 그래서 11명을 뽑는 방법은 35C11이 된다.

만약에 35명 이상의 사용자를 받는다면? => 확률이 커진다.

패킷 스위칭이 데이터를 전송하는 구간에서는 한꺼번에 데이터 전송이 일어나고 상당 기간동안 전송하지 않은 상태가 일어나는 것이 bursty data인데 이럴 경우에는 패킷 스위칭이 잘 작동한다.

Resource sharing을 하기 때문이다.

패킷스위칭은 서킷스위칭 보다 단순하다. (서킷스위칭은 call setup이 필요하다. 그래야지만 자원을 예약하고 할당할 수 있기 때문이다.)

Packet delay 와 loss에 의해서 과도한 혼잡상황이 벌어질 수 있다. 서킷스위칭에서는 딱 정해진 사용자만 받아서 서비스 하지만 패킷스위칭에서는 그보다 훨신 더 많은 사용자를 수용해서 서비스 하기 때문이다. 그래서 신뢰성 있는 데이터 전송, congestion control등을 위해 프로토콜이 필요로하게 된다.

Circuit-like behavior의 제공 방법이 있나?

즉 패킷스위칭에서 보장성 있는 행위를 제공해줄 수 있는 방법이 있는지 의문이 발생할 수 있다. 이전의 인터넷 서비스는 텍스트 위주였지만 오디오나 비디오, 즉 멀티미디어 어플리케이션이 대부분 차지하게된 인터넷 상황에서는 bandwidth를 보장해주는 서비스가 필요하게 된다.  그래서 이 문제를 풀기위해 계속 노력중에 있다.

인간사회에서 유사한 사례

서킷 스위칭 : 음식점 예약, 기차표 예약, 등등…

패킷 스위칭 : on demand allocation

[네트워크 코어에서 사용할 수 있는 또다른 스위칭 방식에 circuit switching이 있다. (회선 교환 이라 부른다.)]

서킷 스위칭 방식은 패킷 스위칭이랑 많이 다르다. 

서킷스위칭 방식은 전통적인 전화망에서 사용이 되었다. 

서킷스위칭 방식에서는 source와 destination사이에 call(전화 통화)을 위해서 end-end간에 resource(자원)을 예약하고 할당하는 방식을 취한다. (패킷스위칭에서 없었던 방식)

다이어그램(옆 그림)을 보면 각 링크가 4개의 서킷으로 나누어 져 있다. (가상의 회선임. 물리적으로 쪼갠게 아닌 논리적으로 쪼개놓은거임. 쪼개는 방식은 다음에 배운다고함)

 call을 통하는 top에서는 2번째 서킷 오른쪽에서는 첫번째 서킷을 차지한다. 즉 예약하고 할당해서 사용하게 된다. 

이 resources는(왼쪽 위, 오른쪽 밑 컴퓨터) dedicated 방식으로 사용하게 된다. 즉 전용으로 쓰는것이다. 공유를 안하고, 회선처럼 보장되는 성능을 담보할 수 있다. (패킷스위칭 방식이랑 다른점이다.)

저 두개의 resource가 아무런 통화작업, 또는 전송할 데이터가 없더라도 다른사람은 이 회선은 쓸 수 없다.

위와 같은 방식이 전통적인 전화망에서 사용되면서 전화 품질을 일정수준에서 유지시켜줬다.

[FDM versus TDM]

FDM (주파수 분할 다중화) 

y축은 주파수, x축은 시간.  Frequency band를 쪼개어 사용자 4명을 가정했을 때 각각의 유저에게 각자의 것을 할당해주는 것이고 각자의 노선만 쓸 수 있다.

TDM (시분할 다중화)

frequency band를 쪼개는게 아니라 link를 사용하는 시간을 짤라 번갈아가며 쓰는 방식이다. 주기적으로 각자가 쓸 수 있는 시간이 돌아온다. 시간마다 쓸 수 있는 시간이 있고 해당 시간에는 해당 유저만 사용 가능하다.

위 두 방식 둘 다 dedicated 방식으로 사용하게 된다. 

routing과 forwarding이 있다.

routing은 패킷 스위치에 패킷들이 source부터 destination까지 거치게 되는 루트를 결정하는 것이다. rouing algorithm에 의해서 경로 계산이 된다. 이렇게 계산된 경로에 따라서 각각의 라우터에서는 local forwarding table을 만들게 된다. 이 table에서는 source부터 destination까지 가는 경로를 거쳐가기 위해서는 해당하는 라우터에서 output link 뭐를 선택해서 나가면 이 경로를 타게되는지를 표시하는 테이블이다. (그 output link를 각각 패킷의 header value(해더값)에 의해서 정해지게 된다.

forwarding이라고 하는것은 패킷들을 라우터의 input으로 부터 routing에 의한 적절한 router output쪽으로 패킷을 옮기는 작업이다. (라우터가 하나의 interchange라고 하면은 각각의 interchange에서 어느길을 택해야 하는지를 결정하는 것이다.)

*interchange : 교차로

[페킷스위칭 방식에서는 store and forward 방식이 사용됨(저장하고 전송한다는 뜻)]

각 패킷당 L bits로 이루어 져 있다. 

Link capacity는 R bps로 가정했다. 

전송을 한다는 것은 해당 패킷을 링크에다가 올리는 작업을 얘기함.  

패킷을 쏘면은 링크를 거쳐서 전파가 되어서 라우터에 도착하게 되는데 라우터에 쌓이는 모습이다. 다음 링크로 바로 전송해도 될 것 같지만 그게 아니라 라우터에서 다 채워질 때 전송이 된다. 그래서 (store and forward 이다.)

source로 부터 다음 라우터 까지 가는 시간은  L/R이다. (전파 되는데 딜레이 되는 시간은 0으로 가정한다.)

[페킷 스위칭에 queueing delay, loss가 있다.]

라우터에 A와 B로 부터 패킷들을 받고 있다. 도착한 패킷들을 머물렀다가 내 보내야 하는데 머무는 메모리 또는 버퍼를 “queue”라고 부른다. (FIFO의 성질을 가지고 있으며 먼저 도착한 서비스를 먼저 내보낸다.)

이때 queue에서 기다리는 시간이 존재하는 것이queueing delay이다.

queueing and loss

링크의 arrival rate(도착률)이 일정 기간 동안에 링크에 transition rate(전송률)을 초과하는 경우에 

• 패킷들은 queue에 보관이 되서 링크에 전송되기를 기다리게 된다.
• queue를 형성하고 있는 버퍼나 메모리가 꽉 차면 그 뒤에 오는 패킷들은 버려지게 된다.

[네트워크 코어]

• 라우터들이 연결되어있는 모습이 네트워크 코어가 형성되어 있다고 말한다.  
• 네트워크 코어에서는 패킷스위칭 방식( 패킷교환 방식)을 사용한다.
• 패킷 교환 방식에서는 호스트가 어플리케이션 레이어의 메시지를 좀더 작은 데이터 덩어리로 자른다. (이 메세지의 덩어리를 패킷으로 부른다.)
• 쪼개진 패킷들은 각 라우터에서 라우터로 전송이 되게 되는데 전송이 될 때 커뮤니케이션 링크를 타고 전송이 된다.
• 요소(source)로 부터 도착지 까지 경로를 따라서 각각의 링크를 거쳐 패킷 전송이 된다.
• 패킷스위칭 방식에서 각 패킷은 링크에서 사용할 수 있는 최고속도로 전송되게 된다.  (패킷 하나를 전송할 때 다른거 안하고 해당 패킷만 전송한다는 것, 즉 한번에 링크를 사용할 수 있는 것은 하나디.)

TLS record protocol을 살펴보면은 TLS는 handshake 프로토콜만 있는게 아니라 record 프로토콜도 같이 있는데, handshake 프로토콜에서 세션 키, MAC 키 를 결정해서 응용 메시지를 전달 할 때 MAC키를 이용해서 메시지 인증 (HMAC)을 만들고 다음으로, 세션 키로 암호화 시켜서 응용 프로토콜에 메시지를 보내게 된다. 그 과정에서 바로 TCP segment로 보내지 않고 TLS Layer에서 그것을 record로 만들어서 그것을 TCP로 보낸다. TCP segment로 만들어서 실제 망에서 전달이 일어나게 되는데 그렇게 record로 만드는 과정을 하나 더 집어넣은 이유는 TCP자체가 byte stream개념이기 때문이다. 그러니까 record를 만드는 layer를 하나 더 집어넣었다. 어플리캐이션에서 부터 내려오는 데이터를 record로 만들면서 record1,2,3,4,5 이런식으로 record 단위로 보게된다. 그래서 record 단위로 MAC을 붙이고, 또는 암호화를 하게된다. 

처음에 인증을 하고 키를 설정하는 과정에서 TLS handshake프로토콜을 거치면서 세션 키와 MAC 키가 결정되게 되면 응용 프로토콜 메시지는 TLS record가 만들어져서 전달이 이루어지게 된다. 

클라이언트와 서버는 둘만이 아는 PMS값을 갖는다고 했다. 키를 계산하는 과정은 다음과 같다.

• Master secret( MS ) , pre-master secret (PS), Client random (CR), Server random (SR)

MS = MD5( PS || SHA-1(‘A’ || PS || CR || SR)) ||  

(PS, CR, SR) 순으로 MS 값을 계산한다. 복잡해 보이지만 쭉 연결 시켜서 SHA-1으로 해쉬 시키는 방식으로 한 것이다. 

결국에는, MS에서 키를 만들어 내는데 키는 하나가 아니라 여러개의 키를 만들어 낸다. 세션키, MAC키, 초기값을 만든다.

Client nonce, server nonce, master secret으로 부터 다음의 키를 계산한다.

• Server MAC key  => (HMAC 해쉬하기 위함, 암호화를 하기 위한것 x)
• Client MAC key  => (HMAC 해쉬하기 위함, 암호화를 하기 위한것 x)
• Client encryption key  => 세션키(암호화 키)
• Server encryption key => 세션키(암호화 키)
• Server initialization vector (IV)  => 대칭키 암호화 알고리즘에 사용하는 초기값
• Client initialization vector (IV)  => 대칭키 암호화 알고리즘에 사용하는 초기값

위에 키들이 비슷한 것들이 두 개인 이유가 서로 클라이언트와 서버 양 방향에서 사용하기 때문이다.

정리하자면 PS에서 MS를 계산하는데 이 때 계산하기 위해서 같이 사용 하는 것이 CR, SR이다. 즉 MS를 PS, CR, SR로 계산한다. 그리고 MS로 부터 6개의 키 값들을 계산한다.

MS = MD5( PS || SHA-1(‘A’ || PS || CR || SR)) ||  

‘A’ 와 같은 캐릭터 스트링에 다가 PS, CR, SR을 쭉 연결해서 해쉬 해서 MS를 만들고 MS를 가지고

MD5( MS || SHA-1(‘A’ || MS || SR || CR)) ||

MS를 SR, CR을 쭉 연결 시켜서 고정된 캐릭터 스트링에 다가 해쉬해서 나오는 결과값을 일정 한 길이로 잘라서 각각을 키로 사용 한다. (밑에 그림 참조)

다음 네 가지 방법을 이용하여 키 교환/설정을 한다.

RSA - 공개키를 이용해서 세션키를 설정하는 경우에는 클라이언트는 세션키를 만들었다면 이 세션키를 서버에 공개키로 암호화 해서 전송을 하면은 서버는 안전하게 클라이언트가 만든 세션키를 받을 수  있다. 그래서 server_key_exchange에는 전송할 정보가 없다. 

Fixed Diffie-Hellman - 인증서 안에 서버가 자신의 Diffie-Hellman 파라메터를 클라이언트에게 알려주면 클라이언트 입장에서는 서버의 Diffie-Hellman 파라메터를 받았으니까 server_key-exchange에는 따로 전송할 정보가 없다. 이 DH경우에는 중간자 공격의 위험은 없 왜냐하면 서버가 보내는 DH파라메터는 인증기관이 서명하니깐 누가 중간에서 그걸 가지고 장난칠 수는 없기 때문이다. Ephemeral DH와의 차이가 뭐냐면 DH파라메터가 인증서를 보낼 때 고정되니깐 그 인증서에 나와있는 DH파라메터를 계속 사용을 하게 되는데 ephemeral DH는 필요할 때마다 서버가 자기 비밀 값을 보내주니깐 DH값을 일시적으로 사용할 수 있다. ephemeral을 사용하는 이유가 인증 프로토콜에서 순방향 안정성(FS: Forward Security)을 이용해가지고 ephemeral DH를 사용한다. 

ephemeral Diffie-Hellman - 가장 안전한 키 설정 방법이다. (forward security도 보장을 해줌) 이 경우에는 인증서에는 서버의 공개키를 전송한다. 이것만 보면 RSA 의 경우와 같지만 자신의 Diffie-Hellman 파라메터를 server_key_exchange에 포함해서 클라이언트에게 전달하게된다. 그 때 그 파라메터는 자신의 개인키로 서명을 해서 “이거는 내가 보내는것이 맞다”라는 것을 확인한다. 서버가 개인키로 서명을 했기 때문에 Diffie-Hellman의 경우에는 MITM(Man In The Middleattack)-중간자공격에 위험성이 있는데 ephemeral Diffie-Hellman은 개인키로 서명해서 보내기 때문에 MITM은 가능하지 않다. 

Anonymous Diffie-Hellman - 이건 일반적인 DH(Diffie-Hellman)이다. 가장 안전하지 않는 방법이고 이 경우에는 MITM에 취약하다.

이러한 암호 방식 리스트를 주고 받으면서 클라이언트와 서버 간에 어떤 암호 알고리즘, 해시 알고리즘, 키 교환방식을 쓰는지를 서로간에 합의를 해서 결정하게 된다. 

암호 알고리즘, 해시 알고리즘, 전자 서명 방식, 키 교환 방식을 결정하게 된다.

클라이언트가 자신이 사용할 수 있는 리스트를 서버한테 주면은 서버가 그 중 하나를 선택하게 되는데

RSA, DH_DSS, … 이런것들이 키 설정 방식을 의미한다. 

키 설정 방식을 간단하게 설명 하면 두 가지 방식이 있는데 1. 공개 키 방식 2. Diffie-Hellman 방식이 있다.

• RSA는 공개 키를 사용해서 세션키, 대칭키를 설정하는 방식이다.
• 나머지 DH_DSS, DH_RSA, DHE_DSS, DHE_RSA, DH_anon은 Diffie-Hellman 방식을 사용하는건데, 이 경우는 세 가지로 구분 되어 있다. 1. DH_DSS, DH_RSA는 fixed Diffie-Hellman 방식 2. DHE_DSS, DHE_RSA는 ephemeral Diffie-Hellman 방식 3. DH_anon는 anonymous Diffie-Hellman 방식 이 있다. 결국 키 설정은 Diffie-Hellman의 세 가지랑 공개 키 방식을 놓고 보면은 네 가지 있다고 볼 수 있다.

AES는 암호 알고리즘을 의미한다. 어떤 알고리즘을 사용 할 것인가를 말한다. 그리고 CBC는 블록체인을 말한다. 결국 AES000_CBS까지가 어떤 알고리즘을 사용 할 것인지를 말해준다.

SHA_256은 해쉬 알고리즘을 얘기한다. 

그러나 전자 서명 방식은 다른 필드에 표현되어있다.