I2P 개발자 회의 - 2004년 12월 28일

13:06 <@jrandom> 0) 안녕하세요 13:06 <@jrandom> 1) 0.4.2.5 13:06 <@jrandom> 2) 0.5 13:06 <@jrandom> 3) ??? 13:06 <@jrandom> 0) 안녕하세요 13:06 * jrandom 손을 흔든다 13:06 <+postman> *손흔듦* 13:06 <ant> <jnymo> hello 13:06 <@jrandom> 간단한 상태 노트를 http://dev.i2p.net/pipermail/i2p/2004-December/000535.html 에 올려놨어요 13:07 <@jrandom> 그럼 1) 0.4.2.5로 들어가죠 13:07 <@jrandom> 말한 대로, 대체로 잘 돌아갑니다 13:08 <+postman> 응, 꽤 인상적이야 13:08 <+postman> 내 시스템들에서는 더 이상 리스(lease) 타임아웃이 전혀 없어요 13:08 <@jrandom> 많은 사람들이 네가 본 걸 봤어, jnymo. 참여하는 tunnel이 0인 경우 말이야. 효율 증가와 피어 선택 덕이 큰데(이젠 postman의 머신을 빨아먹는 법도 알았고 ;) 13:08 <ant> <jnymo> 저도요 13:08 <@jrandom> 좋네 13:08 <ant> <jnymo> 그리고 eepsites가 빠릿해요 13:09 <+postman> :) 13:09 <ant> <jnymo> 고마워요 postman :) 13:09 <+postman> 총 bw는 29kb / 30.1kb/s 13:09 <frosk> 모두가 사랑을 덜 받는다고 느끼지만, 사실 사랑은 더 효율적으로 쓰이고 있을 뿐 13:10 <ant> <jnymo> 와우 13:10 <@jrandom> 끝내주네, postman 13:10 <mule2> 그게 우리가 지향하는 이상이라고 생각하진 않아요. 모든 노드를 통해 어느 정도 트래픽이 흐르는 게 낫겠죠 13:10 <ant> <jnymo> 사람들이 나만 좀 사랑해준다면 감당할 수 있을 텐데 :( 13:10 <+postman> 맞아 13:10 <mule2> 일종의 커버 트래픽으로요 13:10 <@jrandom> mule2: 부하가 네트워크 용량보다 훨씬 적다는 문제일 뿐이에요 13:11 <@jrandom> 용량이 부하보다 큰 상태를 오래 유지하긴 어려울 거라 봐요 13:11 <ant> <jnymo> mule2, postman은 믹서 역할도 해서.. 패킷이 들어간 뒤 어디로 가는지 파악하기가 어렵죠 13:11 <@jrandom> 그래서 느린 피어를 통해 데이터를 안 밀어도 크게 걱정하지 않아요 13:12 <mule2> 아마 완벽하지 않은 최적화가 익명성에 더 좋을지도 13:12 <@jrandom> 반면, 더 많은 사람이 i2pcontent를 (구현하고) 쓰도록 동기를 주기도 하죠. 그러면 미러링도 하고 커버 트래픽도 얻을 수 있으니까 ;) 13:12 <jdot__> 한 router가 거의 모든 tunnel을 처리하는 게 보안 문제인가요? 13:13 <@jrandom> mule2: 먼저 가능한 한 좋게 만들고, 그다음 의도적으로 나쁘게 만드는 방안을 논의하죠 13:13 <@jrandom> jdot__: 모든 트래픽을 처리하는 단일 router가 있는 건 아니고, 아주 빠른 연결(colo 등)에 있는 router들의 집합이 전화접속/DSL/케이블 사용자들보다 더 많이 처리하는 현상을 보고 있어요 13:14 <@jrandom> 게다가 tunnel 실패가 줄어들면서 경로 전환과 탐색도 줄었고요 13:14 <mule2> router의 한계에 한참 못 미친다면 트래픽 분산을 하는 방법도 가능하지 않을까요 13:14 <@jrandom> 맞아요, 확률적 tunnel 거부 기능이 router에 있고, router의 대역폭 한계를 기준으로 활성화할 수 있어요 13:15 <ant> <jnymo> 맞아요. 하지만 postman의 노드처럼 처리량이 높은 경우엔 그 노드를 분석하기가 더 어려워져서... 모든 노드가 1KB/s씩 쓰는 것보다 그를 통해 보내는 편이 더 안전할 수도 있죠 13:15 <@jrandom> (하지만 postman이 제한을 안 걸면 그 기준의 %로 거부하질 못해요 ;) 13:15 <ant> <jnymo> 빠른 노드들의 그룹이 일종의 믹스 캐스케이드 구조를 만들죠, 그렇죠? 13:15 <@jrandom> 맞아요, 그렇게 볼 수도 있죠 13:15 <lektriK> Start I2P 창을 닫아도 되나요? 13:15 * postman은 자신의 대역폭에 제한을 두지 않아서 매우 미안해함 13:16 <@jrandom> lektriK: 안타깝지만, I2P를 서비스로 시작하지 않는 이상은 어렵습니다(보기: http://localhost:7657/configservice.jsp) 13:16 <@jrandom> 헤헤 postman, 걱정 마세요. 우리가 당신의 router 용량에 도달하면 그때는 부하를 줄일 겁니다 13:17 <lektriK> 좋아요, 'service started'라고 나오네요 13:17 <lektriK> 이제 닫아도 될까요? 13:17 <@jrandom> lektriK: 아니요/예요 - router를 종료한 다음 start->run->"net start i2p"로 다시 시작할 수 있어요 13:18 <mule2> 지금 상태로는 아주 큰 router 몇 개가 모든 tunnel을 처리해서 다른 router들의 커버 트래픽이 사라질 수도 있어요. 하지만 그 얘기는 회의 끝나고 계속하죠. 13:18 <mule2> 네트워크가 너무 잘 돌아간다고 불평하고 싶진 않아요 :) 13:18 <@jrandom> 헤헤 13:20 <@jrandom> 0.5에서는 추가적인 탐색이 있을 텐데, 너무 멀리 퍼지면 익명성과 관련된 문제가 있어요. 그 부분은 0.5에서 더 다듬어야 하고(초안 문서는 다음 주에 준비될 수도 있어요) 자세한 내용이 더 있을 겁니다 13:21 <@jrandom> 아무튼, 0.4.2.5에 대해 더 얘기할 거 있으신가요? 13:21 <@jrandom> 아니면 잠깐 2) 0.5로 넘어갈까요? 13:21 <+postman> 넘어가자 13:21 <ant> <jnymo> 매우 안정적... 넘어가요 13:21 <@jrandom> 넘어간 걸로 하죠 13:22 <@jrandom> 2) 0.5 13:22 <@jrandom> 그래요. 아직 작업 중입니다. 준비되면 더 알려드릴게요. 13:22 <ant> <Quadn-werk> 아서 C. 클라크 경이 살아있대요 :P 13:22 <ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1 13:22 <ant> <jnymo> .5는 기대돼요 13:22 <@jrandom> 좋아요, 그에 대해선 할 말은 여기까지 - 질문이나 논의할 거 있으신가요? 13:23 <@jrandom> 네, 지난 16개월 13:23 <@jrandom> (아니, 젠장, 18개월) 동안 배운 걸 바탕으로 중요한 개편이 진행 중입니다 13:23 <+postman> jrandom: 그럼 0.5는 주로 새로운 tunnel 관리 시스템을 도입하나요? 13:23 <ant> <Quadn-werk> 으, 회의를 방해하지는 않았길 :/ 13:23 <+postman> 와우 13:23 <ant> <Quadn-werk> 미안 헤헷 13:23 <ant> <jnymo> 헤헷, 제안이 있었어요 13:24 <@jrandom> 맞아요 postman, 새 관리, 풀링, 그리고 구축 13:24 <+postman> quadn: 이것 봐요 - 붙여넣기 때문에 넷스플릿이 났어요 :) 13:24 <@jrandom> 이 못된 녀석! 13:24 <ant> <Quadn-werk> ! 13:24 <@jrandom> 무슨 일이야, jnymo? 13:24 <+postman> jrandom: 각 tunnel이 여전히 별도의 local Destination이 될 건가요? 13:25 <@jrandom> 뭐라고요? 13:25 <@jrandom> 0.5에서는 i2ptunnel에 변경이 없을 거예요 13:25 <+postman> jrandom: 오케이 13:25 <@jrandom> (적어도, 그럴 계획은 없어요) 13:26 <mule> postman이 인터섹션 공격(교차 추적 공격)을 시도 중인가? 13:26 <ant> <jnymo> 대역폭 사용량이 /전혀/ 없는 사람들을 위해... router가 그들을 포함한 tunnel을 만들게 하는 건 어때요... 예를 들어 ABCABCA처럼 13:26 <+postman> mule: 아니요, 그건 quadn 잘못이에요 :) 13:26 <ant> <jnymo> 그리고 그건 더미 tunnel이죠 13:27 <@jrandom> jnymo: router를 "여유 대역폭 있어요, 저를 쓰세요"라고 광고하는 건 위험한 일입니다 13:27 <+postman> jrandom: 그럼 재설계로 어떤 이슈들이 다뤄지나요 (간단히 말해서) 13:27 <ant> <jnymo> 제가 말한 건 그게 아닌데요, jrandom 13:27 <@jrandom> 하지만 현재로선 두 가지 종류의 tunnel을 갖게 될 듯해요 - 일반 tunnel과 탐색용 tunnel로, 후자는 실패하지 않는 피어 중 무작위로 선택해 구성합니다 13:28 <ant> <jnymo> jrandom: 제 말은 더미 tunnel을 만들고, 트래픽을 흉내 내려는 목적으로 제 자신을 그 tunnel의 중간에 넣는 거였어요 13:29 <@jrandom> postman: tunnel 내 피어를 상관관계로 묶기 훨씬 어렵게 만들고, 클라이언트가 자신의 아웃바운드 tunnel 길이를 효과적으로 선택할 수 있게 하며, predecessor attack(선행자 공격)을 다루는 데 필요한 선택지들을 제공합니다(여러 가지 트레이드오프 포함) 13:29 <@jrandom> (아, 그리고 많은 modPow 호출을 없애 성능도 개선해요) 13:29 <+postman> 고마워요 13:29 <ant> <jnymo> postman: 그리고 hop마다 다른 tunnel ID도 큰 변화죠 13:30 <+postman> modpow? 13:30 <@jrandom> 아, jnymo. 네, 여러 가지 chaff 트래픽(쓸모없는 교란 트래픽) 생성 가능성이 많아요 13:30 <ant> <jnymo> 그런 식이면, 인접하지 않은 두 노드는 같은 tunnel 위에 있다는 걸 알 수 없게 돼요, postman 13:30 <@jrandom> postman: 모듈러 지수 연산, CPU 사용량이 크고 메모리 낭비도 큽니다 13:31 <ant> <jnymo> jrandom: 오키 쿨 13:31 <+postman> ㅇㅋ 13:31 <scintilla> jrandom, 클라이언트가 tunnel 길이를 선택하도록 하는 것과 관련해: 사람들이 99(혹은 그 이상)로 올려버리는 걸 막는 장치가 있나요? 13:31 <ant> <jnymo> CPU 성능 13:32 <@jrandom> 필요하면 hashcash를 추가할 수 있지만, 지나치게 긴 tunnel은 어차피 실패하게 될 겁니다 13:32 <scintilla> 아, 좋은 지적 13:32 <@jrandom> 이런 꼼수도 넣을 수 있어요 - 생성 후 60초 안에 유효한 tunnel 메시지가 그 tunnel을 통과해야만 '유효'로 인정하도록 하는 거죠 13:33 <@jrandom> (그래서 tunnel이 20 hops라면, 그 모든 hop을 만드는 데 시간이 너무 오래 걸릴 겁니다) 13:33 <scintilla> 멋진 생각이네요 - 그런 황당한 시도가 오래 지속되지 못하게 하겠죠 13:33 <@jrandom> 하지만 그건 해커들 상대일 뿐이고, 일반 사용자는 노출된 인터페이스만 쓰게 될 겁니다 13:34 <ant> <jnymo> 맞아요, 어디선가 상한을 두겠죠? 13:34 <ant> <jnymo> 지금 최대 2보다 더 높게 설정할 수 있게 되는 거죠? 13:34 <@jrandom> 맞아요, /configclients.jsp나 /i2ptunnel/edit.jsp의 # hops 드롭다운 같은 데서요 13:35 <@jrandom> 어, 지금 최대가 3인 줄 알았는데요? 알겠어요, 어쨌든 2보다 큰 값은 가능해요 13:35 <ant> <jnymo> tunnel 3개, hop 2개 13:35 <@jrandom> 아 'k 13:35 <@jrandom> 네, 0.5에서는 길이를 랜덤화할지, 또 어느 정도로 랜덤화할지 등 중요한 조정 옵션들이 추가됩니다 13:36 <frosk> 최대는 확실히 3이에요 13:36 <ant> <jnymo> 흐음 13:37 <@jrandom> 아, /configclients에서는 3이고 i2ptunnel에서는 2군요 13:37 <frosk> 0.5는 여전히 1월 공개 일정에 맞춰 진행 중인가요? 13:37 <ant> <jnymo> 아하 13:37 <@jrandom> 네 frosk 13:37 <frosk> 좋네요 13:37 <@jrandom> 스트리밍 라이브러리에 더 이상 꾸물거리지 않겠다고 약속할게요 ;) 13:37 <frosk> 일이 엄청 많아 보일 뿐이에요 :) 13:38 <@jrandom> 실제로는 그리 나쁘지 않아요, 어려운 건 알고리즘을 제대로 잡는 거죠 13:38 <@jrandom> (자질구레한 건 됐고 ;) 13:39 <+postman> frosk: 그리고 이미 문서로 다 정리돼 있어요 13:39 <+postman> :) 13:39 <ant> <jnymo> 헤헷 13:39 <frosk> 그렇죠 :) 13:39 <@jrandom> 대부분은요 ;) 13:39 <@jrandom> 좋아요, 2) 0.5에 대해 더 있을까요? 13:39 <ant> <jnymo> 없어요 13:39 <frosk> 전혀 없음 13:40 <@jrandom> 'k, 그럼 예전처럼 3) ???로 넘어가요 13:40 <@jrandom> 안녕하세요 13:40 <@jrandom> 다른 얘기할 거 있으신가요? 13:41 <ant> <jnymo> postman: i2pmail.org에 SMTP/POP3 inproxy는 없죠? 13:41 <cat-a-puss> 클라이언트 쪽에서 아직도 이상한 지연이 보여요... 13:41 <+postman> 흠, 아니요 13:41 <frosk> 여기서 훌륭한 한 해의 개발을 축하하며 와인 한 병을 건네야죠 ;) 13:41 <+postman> jnymo: POP3는 I2P 사용자에게만 제공돼요 13:41 <@jrandom> cat-a-puss: 아, 아까 있었을 때 그 메시지를 놓쳤네요 13:41 <+postman> jnymo: i2pmail.org 도메인의 MX로 SMTP inproxy는 있습니다 13:42 <@jrandom> frosk: 건배 13:42 <ant> <jnymo> 맞아요 맞아.. 그거 멋지네요.. 13:42 <cat-a-puss> 예를 들어 local Destination을 두 개 띄워놓고 하나가 다른 하나에 연결을 시도할 때 지연이 있고, CPU 병목은 아니에요 13:42 <mule> cat-a-puss: 보너스 수표도 함께 주나요? 13:42 * postman 좋은 위스키를 기부함 13:42 <@jrandom> cat-a-puss: 맞아요, 0.5~1.0초 지연을 봤다고 했죠? 13:42 <cat-a-puss> mule: 뭐요? 13:42 <cat-a-puss> jrandom: 네 13:43 <@jrandom> cat-a-puss: 완전히 정상이에요, 지연된 SYN의 일부예요 13:43 <mule> 미안, 그 코멘트는 frosk가 한 거였어 13:43 <ant> * jnymo 형편없는 박스 와인을 꺼낸다 13:43 <mule> frosk: 보너스 수표도 함께 주나요? 13:43 <@jrandom> (더 묶을 데이터가 있을 수 있어서 SYN과 관련 ACK 전송을 잠깐 기다립니다) 13:43 <scintilla> 참고로, 곧 Fortuna 알고리즘 명세가 실린 책을 받을 것 같아요... 그동안에는 시스템을 망가뜨리지 않고 Java에서 엔트로피를 수집하는 방법을 실험해 왔습니다 13:44 <@jrandom> 아, 대박 13:44 <ant> <jnymo> 음, 누가 I2P에 대한 공격을 시도해 보려고 했었죠 13:44 <ant> <jnymo> 누구였죠? 13:44 <@jrandom> connelly 13:44 <cat-a-puss> 그걸 방지할 방법이 있나요, 아니면 가능하면 단명 연결을 피하려고만 해야 하나요? 13:45 <ant> <jnymo> 그건 소식 없나요, jr? 13:45 <@jrandom> cat-a-puss: 네, I2PSocketManager를 만들 때 넘길 수 있는 옵션들이 있어요, 가져와 볼게요 13:46 <@jrandom> jnymo: 그건 장기적인 인터섹션 공격이라서, 시간이 지나면 특정 eepsite가 어떤 router에 있는지 식별하는 데 도움이 되는 데이터를 얻게 될 거예요. 데이터를 모으면 요약을 작성해 줄 거라 확신합니다 13:46 <ant> <jnymo> scintalla: Fortuna 알고리즘이 뭐죠? 13:46 <ant> <jnymo> jrandom: 알겠어요 13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100 13:48 <scintilla> 암호학적으로 안전한 의사난수 생성기예요... 신뢰할 수 있는 암호화를 위해 절대적으로 필수죠 13:48 <jdot__> 그 공격에 자원한 사람 있나요? 13:48 <@jrandom> cat-a-puss: 그리고 I2PSocket에 write()한 다음에는 반드시 flush()하세요 13:48 <@jrandom> jdot__: 네, 자원한 사이트가 7곳 있어요 13:48 <cat-a-puss> jrandom: 좋아요 13:49 <ant> <jnymo> 큰 네이밍 논쟁과 관련해.. 13:49 <ant> * jnymo 킥킥 웃는다 13:49 <@jrandom> 아, 그리고 i2p.streaming.initialAckDelay=1000 13:49 <@jrandom> 아니면 =100까지도 13:49 * jrandom jnymo에게 진흙을 던진다 13:50 <ant> <jnymo> 저는 실제로 X.500을 다루고 있고, 회사에서 무료로 Windows Server를 쓸 수 있어요 13:50 <ant> <jnymo> 그래서 한두 달 안에 테스트용 중앙 DNS를 하나 세워볼까 해요 13:51 <@jrandom> 헤, .mil에서 호스팅되는 중앙 집중식 네이밍 서버라니 정말 웃기겠네요 13:51 <ant> <jnymo> 다만 Windows Server에 I2P 주소를 억지로 넣는 건 만만치 않을 수도... 잘 모르겠네요 13:51 <ant> <jnymo> 헤.. dnsalias가 해법이죠 13:52 <@jrandom> nano가 dnsjava를 I2P와 통합하는 정말 멋진 작업을 했어요 13:52 <ant> <jnymo> 오오오 13:53 <@jrandom> 자세한 내용은 nano.i2p를 확인해 보세요 13:53 <ant> <jnymo> 아무도 내게 말해 줄 생각이 없었군요.. 아, 고마워요 13:53 <@jrandom> 하지만 지난번에 말했듯, 네이밍에 대한 생각과 아이디어는 위키에 올려 주세요 13:54 <@jrandom> 좋아요, 회의에서 더 얘기할 거 있으신가요? 13:55 <ant> <jnymo> 없어요 13:57 <@jrandom> 그렇다면 13:57 * jrandom 팔을 휘두를 준비를 한다 13:57 * jrandom *baf*s로 회의를 종료한다