From owner-rmt@listserv.lbl.gov Tue Feb 8 00:49:33 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29370 for ; Tue, 8 Feb 2000 00:49:33 -0500 (EST) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id VAA18917; Mon, 7 Feb 2000 21:09:36 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA18913 for ; Mon, 7 Feb 2000 21:09:34 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA22212 for ; Mon, 7 Feb 2000 21:09:33 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA22203 for ; Mon, 7 Feb 2000 21:09:32 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (VWALL-IN-motgate 2.0) with ESMTP id WAA14006 for ; Mon, 7 Feb 2000 22:09:31 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id WAA27013 for ; Mon, 7 Feb 2000 22:09:26 -0700 (MST)] Received: from arc.corp.mot.com (t-il06-w-port2.corp.mot.com [129.188.170.92]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id QAA09496 for ; Tue, 8 Feb 2000 16:08:32 +1100 (EST) Message-ID: <389FA4D0.5F79900D@arc.corp.mot.com> Date: Tue, 08 Feb 2000 16:08:32 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: RMT Meeting Agenda, Feb 10 Content-Type: multipart/mixed; boundary="------------F79A41C7056DC60F7258F12F" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------F79A41C7056DC60F7258F12F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMT'ers, A tentative agenda for the feb 10 meeting is attached below. Note that we have deliverately kept the presentations short, as we'd like to maximize the time for discussions. Those of you of have replied and have recevied slots should keep your presentations to roughly 5 slides in bullet form and hit the major points you want to bring up for discussion. If you need to convey additional information please do so by posting it to the list prior to the meeting. However, keep in mind that people are unlikely to read long papers before the meeting. See you on Thursday, cheers, Roger Allison Lorenzo ----------------------------------------------------------------- RMT Interim Meeting Thursday Febraruy 10th, ACIRI 1947 Center st., Berkeley, CA Directions to ICSI are at http://www.icsi.berkeley.edu/where.html Tentative Agenda --------------------------------- 09:00 - 09:10 10 mins Agenda Bashing [Roger] 09:10 - 09:10 10 mins WG status update bb + ds drafts Recharter 09:10 - 09:20 10 mins Call to arms/editorship selection update [Roger] 09:20 - 09:40 40 mins Guidelines Draft Update/Discussion [Roger/Lorenzo/Allison] 10 mins draft outline 30 mins discussion 10:00 - 11:20 1hr20mins Congestion Control: [Handley/Flloyd?] 10 mins TFMCC update [Handley/Flloyd] 10 mins ALC implications for CC [Luby] 10 mins TEAR implications for CC [Rhee] 10 mins Generic source-based multicast CC [Kalyanaraman] 40 mins discussion 11:20 - 12:20 1hr NACK: [Bormann & Adamson?] 10 mins BB Update [Borman] 20 mins BB Discussion 10 mins PI Update [Adamson] 20 mins PI Discusion 12:20 - 13:00 1hr Lunch 13:00 - 14:00 1hr Asynchronous Layered Coding: [Luby] 10 mins BB update 10 mins Gemmell? 40 mins discussion 14:00 - 14:30 1hr Tree-Building: [??] 10 mins table of contents update [Chiu] 20 mins discussion 14:30 - 16:00 1hr TRACK progress [Whetten/Chiu] 10 mins [Whetten] 10 mins [Chiu] 40 mins Discussion 16:00 - 16:45 45 mins VACANT 16:45 - 17:00 15 mins Agenda bashing for Adelaide --------------F79A41C7056DC60F7258F12F Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE -mozilla-cpt:;0;;; url:www.mot.com.au org:Motorola Australian Research Centre;Scalable Commodity Internet Lab version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A= x-mozilla-cpt:;0 fn:Roger Kermode end:vcard --------------F79A41C7056DC60F7258F12F-- From owner-rmt@listserv.lbl.gov Wed Feb 9 01:43:27 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21964 for ; Wed, 9 Feb 2000 01:43:26 -0500 (EST) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id WAA21640; Tue, 8 Feb 2000 22:00:34 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA21636 for ; Tue, 8 Feb 2000 22:00:32 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA14062 for ; Tue, 8 Feb 2000 22:00:23 -0800 (PST) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA14059 for ; Tue, 8 Feb 2000 22:00:22 -0800 (PST) Received: from tahoe ([207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id VAA23403; Tue, 8 Feb 2000 21:58:21 -0800 (PST) Message-Id: <4.1.20000208161711.01d31880@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 08 Feb 2000 16:24:25 -0800 To: smug@baynetworks.com, rmt@lbl.gov From: Brian Whetten Subject: Security Considerations for TRACK Protocols Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_246435064==_" Sender: owner-rmt@lbl.gov Precedence: bulk --=====================_246435064==_ Content-Type: text/plain; charset="us-ascii" Hello all, Sorry for those who get duplicates of this. Please find attached a draft Thomas Hardjorno and I did to analyze the security considerations for TRACK protocols. This is still rough, isn't formatted correctly, and isn't an official IETF draft yet. We will be discussing this at the SMUG meeting on Friday. Brian --=====================_246435064==_ Content-Type: text/plain; name="draft-ietf-rmt-track-security-xx.txt"; x-mac-type="54455854"; x-mac-creator="74747874" Content-Disposition: attachment; filename="draft-ietf-rmt-track-security-xx.txt" Content-Transfer-Encoding: x-uuencode begin 600 draft-ietf-rmt-track-security-xx.txt M#0I);G1E'@N='AT/@T*#0H-"E-T871U`T*("`@;6]N=&AS M(&%N9"!M87D@8F4@=7!D871E9"P@2!O=&AE<@T*("`@9&]C=6UE;G1S(&%T(&%N>2!T:6UE+B`@270@:7,@:6YA M<'!R;W!R:6%T92!T;R!U2!I2!A M;F0@875T:&5N=&EC871I;VXL(`T*9G)O;2!T2!H879E(&%C8V5S2!R M971R86YS;6ET(&$@;&]S="!D871A('!A8VME="`H=VAI8V@@7!T960@#0IU;F1E7!T:6]N M(&ME>2D@=&\@:71S(&]W;B!C:&EL9')E;B`H82!S970@;V8@#0I296-E:79E M7,@#0IS:&]U;&0@8F4@9&EV:61E M9"!U<"!A;6]N9R!G2P@:70@#0ID;V5S(&YO="!P2!O9B`-"G1H92!S M96YD97(@;V8@=&AI2!S97)V:6-E('1O(&QE9VET:6UA=&4@=7-E2!O9B!R96QI86)L92!M=6QT:6-A2!I;G1O('1H92`-"G1H:7)D(&-A=&5G;W)Y(&]F('!R;V)L96US+B`@ M0V]M<&QE=&4@9&5N:6%L(&]F('-E4+"!A2X@(%-O;64@87!P;&EC871I;VYS(')E<75I M65R2!B92`-"F5M<&QO>65D('=I=&@@9&EF9F5R96YT(&UU;'1I8V%S="!R M;W5T:6YG('!R;W1O8V]L2!P M2!I;G-T86YC97,@=&AE('1O<&]L;V=Y(&]F(%)-(`T*:6YF6UM971R>2!C86YN;W0@ M8F4@87-S=6UE9"!F;W(@86QL(&-A7!T:6]N*2!S:&]U;&0@8F4@&%M<&QE+"`-"G1H92!U2!A="!T:&4@25`@;&%Y97(@=&\@875T:&5N M=&EC871E(&UU;'1I8V%S="`-"G)O=71I;F<@<')O=&]C;VP@8V]N=')O;"UP M86-K971S(&-A;B!A;'-O(&)E('5S960@=&\@875T:&5N=&EC871E(%)-(`T* M8V]N=')O;"UM97-S86=E&-H86YG92!C;VYT2!A2!F'0@;&5V96P@=7`@=&AE(&AI97)A2X@(%1H:7,@<')O M8V5S2!O9B!C;VYT2!M=6QT:6-A2!T M:&4@=6YD97)L>6EN9R!M=6QT:6-A("`@("`@("`@("`@("`@("`@("`@("`@("`@("!\#0H@("`@("`@ M("`@("`@?"`@("`@("`@("`@("`@+R`@?"`@7"`@("`@("`@("`@("`@("`@ M("`@("`@("`@('P-"B`@("`@("!(04-+7B`@("`@("`@("`@(%Y>7B`@("`@("`@("`@(%Y> M("`@("`@("`@("`@("`@?"!$871A#0H@("`@("`@("`@("`@("`O('P@("`@ M("`@("`@("\@?"!<("`@("`@("`@("!\(%P@("`@("`@("`@("`@('P@0VAA M;FYE;`T*("`@("`@("`@("`@("`O("!\("`@("`@("`@("\@('P@(%P@("`@ M("`@("`@?"`@7"`@("`@("`@("`@("!\#0H@("`@("`@("`@("`@+R`@('P@ M("`@("`@("`O("`@?"`@(%P@("`@("`@("!\("`@7"`@("`@("`@("`@('8- M"B`@("`@("`@("`@4DX@("!23B`@("`@("!23B`@(%).("`@4DX@("`@("`@ M(%).("`@4DX@("`\+2TM+2TM#0H@("`@("`@("`@("`@("`@("`@("`@("A2 M96-E:79E2!R97%U:7)E;65N=',@9F]R(%1204-+('!R M;W1O8V]L65R M(&EN('=H:6-H('-E8W5R:71Y(&ES(&%P<&QI960Z#0I4:&4@='=O(&QA>65R M2!M96-H86YI7!I8V%L;'D@=&AE(&YE='=O2!T:&4@6UM M971R:6,I(&-R>7!T;V=R87!H>2!I65D(&%N9"!T:&4@:V5Y M(&ES('-H87)E9"!B>2!M;W)E('1H86X@='=O('!A2!C97)T86EN('1H870@=&AE(&5N=&ET>2!T:&%T('-E;G0@=&AE(`T* M;65S6UM971R:6,M:V5Y M+"!A;F0@:7,@=&AU2X-"@T*26X@=&AE(&9O;&QO=VEN9RP@ M=&AE(%1204-+('-P96-I9FEC(')E<75I2!M96-H86YI2!T;R!D;R!S;RX-"@T* M5'=O('1Y<&5S(&]F(&%U=&AE;G1I8V%T:6]N(&UE8VAA;FES;7,@8V%N(&)E M(&%D;W!T960L(&-O7!T;W-Y2!I7!I8V%L;'D@;V8@:&EG:"!I;7!O6UM971R:6,@8W)Y<'1O9W)A<&AY(&%P M<&5A2!B87-E9"!A=71H96YT M:6-A=&EO;B`-"F%P<&5A2!B87-E9"!A=71H96YT:6-A=&EO;BX@#0I4:&5R92!A7!T;V=R87!H>2!W:&EL92!P65D('5S:6YG('-Y;6UE=')I8R`-"F-R>7!T;V=R M87!H>2X@($%L=&AO=6=H(&$@;G5M8F5R(&]F('1E8VAN;VQO9VEE2X@5&AE($EN=&5R:6]R3F]D94ME M>2!I2`-"FES(&EN9&5P96YD96YT(&]F(&%N>2!D871A('-T M2!B92!D97!L M;WEE9"!D=64@=&\@<&5R9F]R;6%N8V4@2P@2!U65D(&AA2!U7!T:6]N("AW:&5R92!A('-U8V-E'0@:7,@8F]T:"!U;FUO9&EF:65D(&EN('1R86YS M:70@86YD('=A2DN#0H-"DAO=V5V97(L(%1204-+('!R;W1O8V]L2D@ M<')E=F5N=&5D(&9R;VT@2!B M92`-"F%D;6EN:7-T97)E9"!A2!R969U6UM971R M:6,@:V5Y(&9R;VT@9&%T82!A=71H96YT:6-A=&EO;B!U65R+"!W:&EL92!D M871A(&%U=&AE;G1I8V%T:6]N('5S:6YG(&$@2!W:6QL M(&)E(`T*8V]N9'5C=&5D(&%T('1H92!N971W;W)K(&QA>65R+@T*#0HM('-I M;F-E('1H92!$4G,O5$X@;6%Y(&)E("AO<'1I;VYA;&QY*2!P2!C;VUE(&9R;VT@=&AE(`T*;W)I9VEN86P@2!C2!T:&4@ M9&%T82`-"BAI+F4N('!A>6QO860I('5N;6]D:69I960@=&\@=&AE('%U97)Y M:6YG(')E8V5I=F5R2!T:&4@ M9W)O=7`M#0IA=71H96YT:6-A=&EO;BX-"@T*5&%K:6YG(&-A2!T:&4@1%(@:7,@<&5R9F]R M;65D('9I82!U;FEC87-T('1O(&$@#0IR96-E:79E2!F;W(@=&AI&ES=&EN9R`-"F=R;W5P+7-H87)E9"!S M>6UM971R:6,@:V5Y(&]R('5S92!A('-E<&%R871E('-Y;6UE=')I8R!K97D@ M;VYL>2`-"F9O2!A;F0@9F]R($%U M=&AE;G1I8V%T:6]N#0H-"D%S(&UE;G1I;VYE9"!A8F]V92P@=V4@<')O<&]S M92!T:&4@2!U2!F;W(@9&%T82!S=')E86T@8V]N9FED96YT:6%L:71Y(&%T('1H M92`-"F%P<&QI8V%T:6]N(&QA>65R(&%S('1H92!'2!O9B!T:&4@1W)O=7!$871A2V5Y+"!W:&EC:"!I2!-86YA9V5M96YT("A'2TTI('!R;W1O8V]L('1H870@#0II9&5N=&EF:65S M(&%N9"!V97)I9FEE2!M=7-T M(`T*8F4@<')E=F5N=&5D(&)Y('1H92!'2TT@<')O=&]C;VP@9G)O;2!O8G1A M:6YI;F<@=&AE($=R;W5P1&%T84ME>2X-"@T*5V4@9&5N;W1E('1H92!S>6UM M971R:6,@:V5Y(&9O'!L:6-I="!G2X@(%5N;&EK92!T:&4@1W)O M=7!$871A2V5Y+"!T:&4@#0I'7!I8V%L M;'D@82!R96-E:79E2!R97-U;'0@:6X@82!D96YI86P@;V8@2!I;7!A8W0@=&AE('-T871E(&]F('1H92!G7!E2!D:7-T2!A7,@:&%V M92!T:&4@861D2!B86-K=7`@1%(O5$XN("!/<'1I;VYA;&QY+"!I="!M M87D@;F5E9"!T;R!K965P(`T*=&AE(&ME>7,@9F]R(&5A8V@@;V8@=&AE(&)A M8VMU<"!C;VYT7-T96US+"!I="!I'!E8W1E9"!T;R!B96-O;64@82!K97)N M96P@;6]D=6QE+"!A;F0@2!M M=7-T(&%C8V]M;6]D871E(&%L;"!T:')E92!O9B!T:&5S92!O<'1I;VYS+B`@ M#0I4:&ES(')A:7-E65R('-E8W5R:71Y(&9U M;F-T:6]N2X-"BT@2V5R M;F5L($EM<&QE;65N=&%T:6]N2!R96-E:79E2P@=6YI;G1E;G1I;VYA;&QY*2!W:&EC:"!W M;W5L9"!C875S92!D96YI86P@#0IO9B!S97)V:6-E+@T*#0I!2U097(M57-E($1A=&$-"@T*02!C;VUM;VX@2UP97(M=FEE=R!V:61E;R!S:6=N86QS+"!O2!O9B!T:&4@87!P;&EC871I M;VX@;&5V96P@2!W:71H(%1204-+('!R;W1O M8V]L2!A="!T:&4@;F5T=V]R M:R!L87EE2!C86X@ M8F4@=7-E9"!I;G-T96%D+2UA;'1H;W5G:"!T:&ES(&]F(`T*8V]U2!W:71H(&]T:&5R(&EM<&QE;65N=&%T:6]N M2!C;W5P;&5D M('1O('1H92!C:&]I8V4@#0IO9B!R96-O;6UE;F1I;F<@25!S96,@9F]R('1H M92!G2!T:&4@9F]L;&]W:6YG.@T*#0HH82D@3F]N+41E M8VEP:&5R86)I;&ET>2!O9B!D871A(&)Y(&EN=&5R:6]R(&-O;G1R;VP@;F]D M97,Z(&ET(&ES(&$@#0IR97%U:7)E;65N="!O9B!44D%#2R!P6UE;G1S+"!I=',@8V]N=')O;"`-"F5N=&ET M:65S("AE+F2!U2!A;F0@1W)O=7!!=71H2V5Y*2!A;F0@=&\@#0II M;G-T2!S:&]W;B!T:&%T('1H92!I;G1E2!! M2!I65R+@T*#0H-"C4N,B!$:79I2!R97-P;VYS:6)I;&ET:65S(&EN('1O M(&9O=7(@#0IP87)T2!A='1A8VMS+@T*+2!/<'1I;VYA;#H@96YC M2!O9B!D871A+`T* M("!A;F0@<')O=FED92!O<'1I;VYA;"!N;VXM7!T:6]N+2UT;R!P7,@<&5R:6]D:6-A;&QY(&YE960-"B`@=&\@8F4@ M8VAA;F=E9"P@8F]T:"!A9G1E2!A9&1I=&EO;F%L('-E M8W5R:71Y(&%T('1H92!)4"])4"`-"DUU;'1I8V%S="!L979E;"P@86QT:&]U M9V@@=&AI2!F;W(@:71S(&YE='=O2`@("`@('P\+2TM+2T^*R`@("`@("`@("`K+2TM+2TM+2TM M*R`@('PM+3Y\("`@("`@("`@('P-"GP@($UA;F%G96UE;G0@('P@("`@("`@ M?"`@("`@("`@("!\("`@5410("`@?"`@("`@("!\("`@25!S96,@('P-"GP@ M("`@("`@("`@("`@('P@("`@("`@*RTM+2TM+2TM+2TM+2TM+2TM+2TM*R`@ M("`@("!\("`@("`@("`@('P-"GP@("`@("`@("`@("`@('P\/3T]/3T^?"`@ M25`L($E0($UU;'1I8V%S="`@?#P]/3T]/3Y\("`@("`@("`@('P-"BLM+2TM M+2TM+2TM+2TM+2L@("`@("`@*RTM+2TM+2TM+2TM+2TM+2TM+2TM*R`@("`@ M("`K+2TM+2TM+2TM+7P-"@T*("`\/3T]/B!/<'1I;VYA;`T*#0H-"E=H96X@ M82!D871A('!A8VME="!I2P@86YD('1H96X@ M8V]N=&EN=64@#0IT;R!D96-I<&AE2X-"@T*02!$97-I9VYA=&5D(%)E8V5I=F5R($YO M9&4@*$12*2!W:6QL('!O2`H8G5T(&YO M="`-"G1H92!'2!O9B`-"F$@2`H2!S M:&%R960@8GD@82!$4B!A;F0@86QL(&ET2X-"@T*06=A:6XL(&%L=&AO=6=H('1H92!C=7)R96YT('=O2!)4'-E8RP@:6YC;'5D:6YG('!R979E;G1I;VX@;V8@2!!2!T:&4@9W)O=VEN9R`-"F%V86EL M86)I;&ET>2!O9B!)4'-E8R!T:&%T(&UO=&EV871E65R(&%U=&AE M;G1I8V%T:6]N(&9O2!M=7-T(&)E(&%B;&4@=&\@875T:&5N=&EC871E M(`T*:71S96QF('1O('1H92!K97D@;6%N86=E;65N="!E;G1I='DO7,N("!792!A7,Z#0H-"B`M("!'2!I2!A;&P@;65M8F5R7!I8V%L;'DL(&]N92!'2!O9B!T:&4@4V5N9&5R+U-O=7)C92!E M;F-I<&AE2!T:&4@4F5C96EV97)S('=I;&P@8F4@86)L92!T;R!D96-I<&AE M2P@=VAI8V@@9&]E2!I2!I65D(&AA2!I3H@#0I4:&4@26YT97)I;W).;V1E2V5Y(&ES(&$@2!S:&%R960@8GD@86QL(&EN=&5R:6]R(`T*8V]N=')O;"!N;V1E M7!T960I(&QO2X@($ET(&UU2!T:&%T(&-H:6QD+412('1O('!R;W9I9&4@ M#0IA=71H96YT:6-A=&EO;B!F;W(@=&AE(')E=')A;G-M:71T960@9&%T82!P M86-K970N("`-"@T*#0HV+B!,:6UI=&%T:6]N2!K97ES+"!A;F0@=&AE(`T*;F5E M9"!T;R!L;V-A;&EZ92!T:&4@969F96-T2!T:&%T($12+@T*#0HH8RD@4')I=F%C>2X@($EN(&]R9&5R('1O('!R M979E;G0@;F5T=V]R:R!T7,@8V%N(&)E('5S960@=VET:"!)4'-E8R!T;R!E;F-R>7!T M('1H92!P86-K971S('-E;G0@=&\@=&AE(`T*9W)O=7`L(&EN(&%D9&ET:6]N M('1O(&1O:6YG('!A8VME="!A=71H96YT:6-A=&EO;BX@($AO=V5V97(L(&ET M(&UUF5D('1H870@=&AI2!O9B!P87DM<&5R+0T*=7-E('-E2!T:&4@#0IR96-E:79E2!B92!A2`H92YG+B!T:&4@2P@ M:6X@=&AE(&-U2!W:6QL(&)E(&-O M;F1U8W1E9"!A="!T:&4@#0IA<'!L:6-A=&EO;B!L87EE65R(&ES.@T*("`@+2!F;W(@<')O=&5C=&EO;B!O9B!T:&4@ M=')A;G-P;W)T(&%N9"!)4"!H96%D97)S+@T*("`@+2!T;R!A;&QO=R!A($12 M('1O(&%U=&AE;G1I8V%L;'D@2!E;F-R>7!T:6]N('1O(&)E(&%P<&QI M960@#0H@("`@("AA="!T:&4@87!P;&EC871I;VX@;&%Y97(I(&EN(&]R9&5R M('!R979E;G0@=&AE($127!T:6]N(&9O65R('5S:6YG(`T*2!C2`-"BAI;G-T96%D(&]F M('1H92!'2!T:&4@#0IE M;G1I=&EE'0L($YO=B`Q M.3DX+@T*#0I;2$@Y.6%=($@N($AA2!A;F0@12X@2&%R9&5R+"`B1W)O M=7`@4V5C=7)I='D@07-S;V-I871I;VX@2V5Y(`T*36%N86=E;65N="!02US<&%R=&$M M9W-A:VUP+7-E8RT-"C`P+G1X="P@36%Y(#$Y.3DN#0H-"EM+0U=0,#!=($TN M($MA9&%N2UT'0L($9E8B`Q.3DX#0H-"EM-1SDX8ET@0RX@36%D7!T:6]N(%-T86YD87)D(BP@5F]L=6UE,2XU+"`- M"DYO+B`Q.3DS+@T*#0I;5T)033DX72!"+B!7:&5T=&5N+"!-+B!"87-A=F%I M86@L(%,N(%!A=6PL(%0N($UO;G1G;VUE; Wed, 9 Feb 2000 13:24:38 -0500 (EST) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id JAA23285; Wed, 9 Feb 2000 09:02:05 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA23281 for ; Wed, 9 Feb 2000 09:02:02 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA20566 for ; Wed, 9 Feb 2000 09:02:01 -0800 (PST) Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA20546 for ; Wed, 9 Feb 2000 09:01:59 -0800 (PST) Received: from tahoe ([207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id JAA06011; Wed, 9 Feb 2000 09:01:07 -0800 (PST) Message-Id: <4.1.20000209085625.01c8b640@mailhost.talarian.com> X-Sender: bwhetten@mailhost.talarian.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 09 Feb 2000 08:58:01 -0800 To: smug@baynetworks.com, rmt@lbl.gov From: Brian Whetten Subject: Security Considerations for TRACK Protocols Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_286204430==_.ALT" Sender: owner-rmt@lbl.gov Precedence: bulk --=====================_286204430==_.ALT Content-Type: text/plain; charset="us-ascii" Someone reported that the file was corrupted, so it is attached below. Sorry to add to everyone's mailbox! Brian Internet Engineering Task Force T. Hardjono INTERNET-DRAFT Nortel Networks draft-ietf-rmt-track-security-00.txt B. Whetten January 12, 2000 Talarian Security Requirements For TRACK Protocols Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document discusses the security issues within TRee-based ACKnowledgement (TRACK) reliable multicast protocols, and identifies some constraints and requirements for security provisions for these protocols. Based on the constraints and requirements, the document proposes a separation of data packet confidentiality and authentication, from transport layer protection. It proposes that TRACK protocols be primarily concerned with group authentication of control and data packets, to protect against attacks on the transport infrastructure. It proposes that data confidentiality and source authentication be provided separately from this low level group authentication, ideally at the application level. We show that this is particularly important for TRACK protocols, because of the requirement that the interior control nodes only optionally have access to the data packet payload. Specifically, the current work proposes that data and control packet authentication be provided using IPsec-based authentication at the network layer. This approach allows an interior control node to authentically retransmit a lost data packet (which remains encrypted under the separate data-encryption key) to its own children (a set of Receivers), while making use of the IPsec features, such as protection against replay attacks. This document then provides a specific proposal for how group keys should be divided up among group members, for control and data packet authentication. While providing some rationale for divorcing this proposal from that of source authentication and data confidentiality, it does not provide a specific proposal for those pieces. 1. Background: The Multicast Security Problem The problem of multicast security can be divided into three general areas of concern: - Data Encryption and Source Authentication. The method used to encipher or scramble the multicast data, and verify the identity of the sender of this data. - Key Distribution. The method used to securely distribute group keys and keying material to the members of a group, for use in decrypting or authenticating the data or control packets. - Infrastructure protection. Mechanisms used to protect the multicast infrastructure itself, and to minimize the ability of an intruder to deny service to legitimate users. The security of reliable multicast protocols falls primarily into the third category of problems. Complete denial of service protection must start at the network level (i.e. IP Multicast), with controls placed on senders from overloading the network with brute force "spamming", as well as with authentication of control packets, to keep users from corrupting the state of the IP Multicast protocols. A transport protocol needs to address the same issues, checking to make sure that senders are not sending more data than they are allowed (such as with enforceable congestion control), and authenticating control packets, to protect the protocol state. Control packet authentication is particularly important in TRACK protocols, because of their use of interior control nodes (for example, in RMTP-II, DRs and TNs) to increase scalability. An optional extension to the requirement of infrastructure protection is that of infrastructure privacy. Some applications require that the headers of the network packets be encrypted, to provide protection from network analysis attacks. 2. Independence of RM Security The security of reliable multicast (RM) protocols is part of the larger problem of the security of the multicast infrastructure, which also consists of the security of the multicast routing protocols. Since RM protocols and multicast routing protocols exist at different layers in the protocol stack, and since different RM protocols may be employed with different multicast routing protocols, it is useful from a security perspective to treat these two security problems separately. In addition, although in many instances the topology of RM infrastructure may coincide with that of the multicast routing protocol, such symmetry cannot be assumed for all cases. Similarly, from a design perspective, the problem of securing the data stream (e.g. through content encryption) should be separated from the issue of securing reliable multicast protocols. Although we treat RM-security as an independent problem from other multicast security problems, this does not preclude using the solutions in other areas in order to solve the security needs of RM. For example, the use of IPsec technology at the IP layer to authenticate multicast routing protocol control-packets can also be used to authenticate RM control-messages. However, the instance of deploying IPsec in both cases must be distinguished and treated separately. 3. RMTP-II Overview While not necessarily typical of all TRACK protocols (such as TRAM [KCWP00]), we use the RMTP-II protocol as an example for analysis and discussion. The RMTP-II protocol features a number of entities which participate in a logical tree or hierarchy and which exchange control- messages with each other. The entities are the Top Node (TN), the Sender Nodes (SD), the Designated Receiver Nodes (DR) and the Receiver Nodes (RN). RMTP-II places receivers into local regions, where each region is assigned to a DR. These groups are arranged hierarchically as a tree rooted at the TN, with the DRs representing the nodes of the tree, and the receivers as the leaves. The senders connect directly to the top node, at the top layer of the hierarchy. The receivers send their control-messages (ACKs, NACKs, etc.) to the DR of their region. Retransmission of lost packets may be done locally by the DR of a domain, or globally from the sender. Each DR sends their control messages to the DR at the next level up the hierarchy. This process is repeated until the TN, who then forwards the control messages to the appropriate sender. The DRs and TN aggregate the positive acknowledgements from the receivers, and suppress the redundant negative acknowledgements, in order to solve the ACK/NACK implosion problem. A DR maintains a local multicast group to just its children, and subscribes to the local multicast group of its parent. A DR uses this local multicast group for retransmissions to its children. While RMTP- II uses multicast for retransmission from a DR, other TRACK protocols may choose to optionally use unicast. RMTP-II distinguishes between a data channel and a control channel. A data channel is a global multicast group created using the underlying multicast routing protocol. A control channel is the interconnected topology of control nodes, for handling error recovery and positive packet acknowledgements. In order to obtain data packets from the Sender, a Receiver in a given RMTP-II region must join the multicast group (i.e. the data channel). The DR of that region must join every multicast group that its descendants have joined. Note that the DRs are not responsible for forwarding the data packets multicast by the Sender, since that data stream is propagated by the underlying multicast routing protocol. The figure below illustrates an RMTP-II tree with multiple control nodes. HACKs -----------> (Top Node)----------------->(Sender node) ^ ^^^ | | / | \ | HACKs | / | \ | | / | \ | | / | \ (Designated | / | \ Receiver | / | \ node) v Control D R D R D R <------------| Channel ^^ ^^^ ^^ | Data / | / | \ | \ | Channel / | / | \ | \ | / | / | \ | \ v RN RN RN RN RN RN RN <------ (Receiver Nodes) 4. TRACK Protocol Security Issues and Requirements This section details the security requirements for TRACK protocols which are similar to RMTP-II. These requirements include general multicast transport requirements, as well as some requirements specific to TRACK protocols. 4.1 Background In addressing the security issues specific to TRACK protocols, it is useful to consider the general aspects of security relating to reliable multicast. - Layer in which security is applied: The two layers in which security mechanisms are deployed are typically the network layer and the application layer. In the network layer the protocol that is the most commonly used is the IPsec protocol, which provides authentication and/or encryption. In either case, with IPsec the transport headers (and IP headers) are protected. When authentication and/or encryption is applied at the application layer, neither the transport headers nor the IP headers are protected. - Types of authentication: - Source-authentication: If public key (asymmetric) cryptography is deployed, where only the sender knows the secret-half of the public key pair, then unique "source-authentication" can be established. - Group-authentication: If shared key (symmetric) cryptography is deployed and the key is shared by more than two parties, then only "group-authentication" can be established. This means that a receiver in a group is only certain that the entity that sent the message is in possession of the symmetric-key, and is thus assumed to be a member of the group sharing the key. In the following, the TRACK specific requirements are further elaborated. 4.2 Authentication of Control-Messages As stated above, the directly relevant security concern for TRACK protocols is protection of the multicast infrastructure, particularly of the control tree, in order to provide protection against replay or other attacks which seek to corrupt the state of the transport protocol. The authentication of control messages exchanged among TRACK protocol entities represents the minimal security mechanisms necessary to do so. Two types of authentication mechanisms can be adopted, corresponding to the two basic types of cryptosystems. In the context of reliable multicast, throughput and latency is typically of high importance, and group-authentication based on symmetric cryptography appears to be preferable. Given this, the efficiencies of symmetric key based authentication appear to outweigh the benefits of public key based authentication. There are potentially cryptographic schemes that can provide the unique source-authentication of public key cryptography while providing the performance characteristics of symmetric key based authentication (e.g. efficient digital signing of the hash-value of several data packets). However, at the present time, for the general case of infrastructure protection, the complexities of these options appear to outweigh the benefits. Thus, in summary, for TRACK protocol control-messages, explicit group- authentication at the IP layer should be deployed using symmetric cryptography. Although a number of technologies are available, we propose specifically IPsec-based authentication using a keyed-hash function [KA98b,MG98a,MG98b] due to its growing use and availability. We denote the symmetric key used for control message authentication as the InteriorNodeKey. The InteriorNodeKey is a symmetric key shared by all DRs and the TN within a given RMTP-II or TRACK hierarchy. The key is independent of any data stream, and is used to authenticate control packets exchanged among the DRs/TN. 4.3 Non-Decipherability of Data Packets by DRs RMTP-II requires that a Designated Receiver Node (DR) join all of the multicast groups that its descendants have joined. This is also true of the Top Node (TN). For TRACK protocols it is preferable that authentication methods based on a symmetric key be deployed due to performance reasons. This may be achieved explicitly, such as by using a keyed hash function, or implicitly using encryption (where a successful decryption implies the ciphertext is both unmodified in transit and was generated by a holder of the symmetric key). However, TRACK protocols have a further requirement, namely that their repair nodes (i.e. DR and TN) be (optionally) prevented from reading the multicast data. More specifically, we perceive that DRs may be administered as part of a reliability service offered by third parties such as ISPs. These third parties may refuse the ability to decipher data packets in order to avoid the legal ramifications of having access to the data contents. Thus, from the ISP perspective, TRACK protocols must allow them to prove to the content-owner that they do not posses the means to alter the contents transmitted through the multicast groups. Given the above requirement of the DRs/TN and the need for fast authentication, we propose: - the separation of data stream confidentiality using either a symmetric or asymmetric key from data authentication using a symmetric key (i.e. explicit group-authentication). - data stream confidentiality will be conducted at the application layer, while data authentication using a symmetric key will be conducted at the network layer. - since the DRs/TN may be (optionally) prevented from reading the multicast data, two (2) different keys must be deployed corresponding to the needs of data stream confidentiality and data group- authentication. 4.4 Authentication of Data Retransmissions In TRACK protocols, retransmissions of data packets may come from the original source, or from a different (DR) node. This local recovery is an important tool for increasing the scalability and latency of a protocol. In the context of security, it raises the question as to what authentication methods should be used on these packets. (a) If source authentication (using public key cryptography) and data confidentiality (including implicit group authentication) is applied at the application layer, the DR can simply replay the data (i.e. payload) unmodified to the querying receivers, either via unicast or local multicast. (b) If, however, explicit group authentication (using a symmetric key) was applied at the network layer (e.g. using IPsec), then the DR cannot simply replay the packet due to restrictions at the IP layer. Thus, in this case the DR must re-apply the group- authentication. Taking case (b) further, there are two options corresponding to whether retransmission by the DR is performed via unicast to a receiver or via multicast. (i) If the retransmission is unicast to a given receiver, then it is preferred if the DR and the receiver share a separate symmetric key for this purpose. (ii) If the retransmission is via multicast to a subgroup (as is the case in RMTP-II), then the DR can either use the existing group-shared symmetric key or use a separate symmetric key only for the subgroup under the DR. We propose to use the later approach, which means that a DR and its children (receivers) must share a separate symmetric key for explicit group authentication at the IP layer. 4.5 Keys for Data Confidentiality and for Authentication As mentioned above, we propose the separation of data stream confidentiality using a symmetric key encryption (effecting an implicit group-authentication) from data authentication using a symmetric key and a keyed hash function (i.e. explicit group-authentication). We now denote the symmetric key for data stream confidentiality at the application layer as the GroupDataKey. Only the source and valid receivers will have a copy of the GroupDataKey, which is delivered to them through the appropriate Group Key Management (GKM) protocol that identifies and verifies the members individually. In the case where the DRs and the TN are not permitted to read the multicast data, they must be prevented by the GKM protocol from obtaining the GroupDataKey. We denote the symmetric key for explicit group-authentication at the network layer as the GroupAuthKey. The GroupAuthKey is distinct from the GroupDataKey. For TRACK protocols, we propose the use of IPsec with keyed hashing at the network layer to provide explicit group- authentication using the GroupAuthKey. Unlike the GroupDataKey, the GroupAuthKey is known by all entities involved in the multicast. This includes all interior node entities (e.g. TN, DR), the Sender/Source and the Receivers. 4.6 Authenticity of NACK and other Control Packets In TRACK protocols, a DR responds to a NACK from one its children (typically a receiver) by re-transmitting the lost packet via local multicast. This basic behavior can be open to abuse by an attacker who injects spurious NACK messages towards the DR, effecting a local multicast to all children of the DR. In itself this is a waste of bandwidth and may result in a denial of resource to the group members. Other control packets directly impact the state of the group, such as the group membership, and could also be used in denial of service attacks. To counter these types of attack, the control messages themselves must be authenticated by the DR. Digital signatures using public key cryptography could be applied to the control messages. However, this approach would be inefficient due to the high CPU cost of public key encryption. Also, it would require creating a separate security association with each child of the DR. Instead, we propose that NACK and other control messages from a child (receiver) to its DR be protected using symmetric IPsec based authentication. This requires the two parties to first establish a Security Association (SA) and a shared symmetric key. The symmetric key can be unique per child, or be uniform over a subgroup of receivers (i.e. those under the DR). 4.7 Fault Recovery In RMTP-II, if a child's connection to a DR or TN fails, RMTP-II provides automatic mechanisms for failing-over to another DR or backup TN. This reconnection needs to happen quickly, so that the child can rejoin the data stream before too much data has been missed to recover from. If a child needs to get a new key for that DR/TN, this can be a bottleneck. Given that the key distribution infrastructure may be centralized, and a majority of receivers may need to fail over at the same time, this presents a major opportunity for network congestion. The RMTP-II entities are given the address of their backup control node at startup time. While these addresses can change, they are expected to always have the addresses of one or more backup nodes. When implementing security features, each child should be required to keep the key for its primary backup DR/TN. Optionally, it may need to keep the keys for each of the backup control nodes it is using. 4.8 Implementation with Different Levels of OS Protection A TRACK protocol can be implemented in (at least) one of three ways. - Application level. Most implementations of TRACK protocols for the near future are expected to operate in the application level of the OS, running on top of UDP. - Kernel. As TRACK protocols become bundled with standard operating systems, it is expected to become a kernel module, and run directly over IP. - Virtual machine. Some TRACK entities (particularly senders and receivers) will be run in virtual machines, such as when implemented as a Java applet. TRACK protocol security must accommodate all three of these options. This raises the following issues. - Application Level. One advantage of application level implementations is their flexibility. These implementations could use either IPsec routines, the application layer security functions, or both. - Virtual Machines. There are issues trying to use IPsec with virtual machines such as Java, which have to date hindered the support of IPsec through native Java applets. This makes it important for a TRACK protocol to optionally be able to use only application level security. - Kernel Implementations. As a TRACK protocol becomes bundled with operating systems, it is expected that IPsec will also become bundled with the OS. To avoid having to use less trusted software in the application level, the TRACK protocol will have to be able to use a kernel level security system (such as IPsec) for its transport level security needs. 4.9 Separate Regional Protection TRACK protocols are expected to be used for content distribution from a few senders to many receivers. In the case of applications that distribute critical data to many different organizations, it is not enough to trust all receivers. For example, a market data feed provider could be using a TRACK protocol to distribute live market data feeds to competing financial institutions. In this situation, the data feed provider needs to be able to protect individual companies from corrupted control packets from other customers (which could be generated either intentionally, or more likely, unintentionally) which would cause denial of service. As we propose in the next section, a TRACK protocol must provide separate regional keys for the group-authentication of control packets sent from the receivers of different DRs. This allows the authentication of control-messages for each set of receivers (part of one customer) to be done separately (from another set of receivers, as part of different customer). Since for each set of receivers a different key is used, this limits the ability of a customer to perpetrate denial of service attacks against other customers. 4.10 Piracy of Pay-Per-Use Data A common scenario for TRACK protocols involves pay-per-use data distribution, such as live market data, pay-per-view video signals, or paid subscriptions to software updates. In this scenario, a receiver cannot be trusted to not give its group keys to outside entities, who are trying to get free service. We mention this requirement since it is different than point-to-point security. However, this requirement is the responsibility of the application level security. 5. Architecture Recommendations The previous section detailed some of the specific requirements and issues for TRACK protocol security, along with some individual recommendation on handling each one. Given those requirements, we propose the following architecture recommendations for implementing security with TRACK protocols. 5.1 Separation of Security Responsibilities As detailed above, TRACK protocols are primarily concerned with protection of the network infrastructure, rather than with issues such as data confidentiality and source-authentication. Therefore, we recommend that TRACK protocols SHOULD provide: (a) group authentication of control packets, and (b) optional group authentication of data packets Optionally, TRACK protocols MAY choose to provide: (c) optional privacy of data and of control packet headers. To accomplish this, we recommend that TRACK protocols use IPsec technology at the network layer, while letting application level security perform additional functions as needed. For implementations that do not have access to IPsec, and are not implemented as part of the OS, application level security can be used instead--although this of course risks incompatibility with other implementations. The separation of group-authentication of data from both data source- authentication and data-confidentiality is tightly coupled to the choice of recommending IPsec for the group authentication. These two choices are motivated by the following: (a) Non-Decipherability of data by interior control nodes: it is a requirement of TRACK protocols that in some deployments, its control entities (e.g. TN, DR) be unable to decipher the data packet. Thus, the GroupDataKey for data encryption and GroupAuthKey for group- authentication must be distinct. It is not sufficient to simply use an identical key (for the GroupDataKey and GroupAuthKey) and to instruct the TRACK protocol entities to avoid deciphering the data packets. It must be provably shown that the interior control nodes do not have the ability to decipher the data packets (even if they wish to do so). (b) Use of IPsec technologies: considerable effort has been invested in developing the IPsec architecture and protocols [KA98a, KA98b], and a growing number of vendors are supporting IPsec. The IPsec suite offers a number of features, including some protection against replay attacks. (c) Multicast IPsec: the IPsec architecture has intentionally allowed the use of IPsec for IP multicast without changes to the basic constructs within the IPsec suite. Currently, work is proceeding towards the establishment of a standard mechanism to select the Group Security Association (Group SA or GSA) for multicast and a method to disseminate the GSA to the valid members of the group [HCM98,HH99a]. (d) Appropriate Level: since the primary purpose of transport level security is to secure the infrastructure at a transport level, using a network or transport level security protocol allows each to be implemented together--either in the OS, or in the application layer. 5.2 Division of Responsibilities Given this fundamental division between application and transport responsibilities, we divide the security responsibilities in to four parts. Network Responsibilities (IP and IP Multicast) ---------------------------------------------- - Admission controls on senders--to protect against "brute force" spamming attacks. - Authentication of routing control packets--to protect the routing infrastructure from denial of service attacks. Transport Responsibilities (TRACK Protocols) ------------------------------------ - Protection of the control messages from replay attacks and other denial-of-service attacks. - Optional: protection of data packets from replay attacks. - Optional: encryption of control messages to minimize network analysis by attackers. End to End Responsibilities (Application) ----------------------------------------- - Source authentication--to verify the authenticity of data, and provide optional non-repudiation of data. - Data encryption--to provide data confidentiality. Key Management Infrastructure ------------------------------- - Distribution of transport and network layer keys: authentication of individual hosts, and distribution of keys to those hosts - Application level key distribution: authentication of individual processes, and distribution of keys to those processes - Optional: periodic rekeying--group keys periodically need to be changed, both after a certain time limit has expired, and/or after the group membership changes. The figure below shows how these components relate to each other. TRACK protocols can be used without any additional security at the IP/IP Multicast level, although this will not provide full protection from denial of service attacks. TRACK protocols will be able to be used on top of UDP or raw IP/IP Multicast. A TRACK protocol can use either IPsec or application level security for its network security requirements, although we recommend using IPsec wherever possible. +--------------------+ +----------+ +--------------+<----->| Application |<----->| App Sec | | | +--------------------+ |==>| | | | | TRACK |<--| +----------+ | Key |<----->+ +---------+ |-->| | | Management | | | UDP | | IPsec | | | +--------------------+ | | | |<=====>| IP, IP Multicast |<=====>| | +--------------+ +--------------------+ +----------| <===> Optional When a data packet is to be sent to the multicast group, the Sender/Source first (optionally) enciphers the data packet using the GroupDataKey above the RM/transport layer. It is then passed to the RM/transport layer, which attaches the necessary RM headers. The result is then passed down to the IP layer where IPsec authentication is established (using the GroupAuthKey). A Receiver in the multicast group would be in possession of both the GroupDataKey and the GroupAuthKey, and thus will be able to first authenticate the data packet using the GroupAuthKey, and then continue to decipher the data packet using the GroupDataKey. A Designated Receiver Node (DR) will possess the GroupAuthKey (but not the GroupDataKey), and thus will only be able to authenticate the packet using the GroupAuthKey using IPsec. After verifying the authenticity of a received data packet, a DR will be able to retransmit the (enciphered) data packet to its children, either via unicast or region-based local multicast. A retransmission of a lost data packet from a DR will be authenticated using a SubgroupAuthKey (see below) which is a symmetric key shared by a DR and all its children Receivers only. Again, although the current work proposes the use of unicast IPsec and multicast IPsec at the network layer, it does not preclude the use of other authentication technologies at the network layer or at the RM/transport layer. Such technologies, however, will have to address much of the same issues faced by IPsec, including prevention of replays, the creation and maintenance of state (i.e. "Security Associations") associated with the GroupAuthKey, the Sender and Receiver(s), and other features and supporting mechanisms. It is precisely the growing availability of IPsec that motivates the current work to choose IPsec for network layer authentication for both data and control packets. 5.3 TRACK Keys In general, each node in the hierarchy must be able to authenticate itself to the key management entity/server, before it will be allowed to receive any of the below keys. We assume the implementation of a key management infrastructure, which interfaces with the DRs and TNs, as well as the senders and receivers. We propose that this key management system be responsible for distributing the following TRACK protocol keys: - GroupDataKey: The GroupDataKey is the unique symmetric key for data encryption shared by all members of a multicast group, excluding the interior tree entities. Typically, one GroupDataKey is associated with one multicast group. The GroupDataKey is used to provide access control to the data packet by way of the Sender/Source enciphering the data packet. Since only the Receivers hold the copy of the GroupDataKey, only the Receivers will be able to decipher the data packets. This is an optional key, which does not directly concern the TRACK transport. - GroupAuthKey: The GroupAuthKey is the unique symmetric key shared by all members of a multicast group, including the interior control nodes. One GroupAuthKey is associated with one multicast group. The purpose of the GroupAuthKey is to provide authentication of the (possibly enciphered) data packets. In the context of IPsec authentication, this can be achieved using a keyed hash function, such as HMAC-MD5- 96 [MG98a] and HMAC-SHA-1-96 [MG98b]. - SubgroupAuthKey: The SubgroupAuthKey is the unique symmetric key shared only by entities within a given local region, consisting of a DR and its children (consisting of one or more Receivers, and possibly one child DR). The SubgroupAuthKey is used by the parent in a local region to provide group-authentication for the (lost) data packets (still enciphered under the GroupDataKey) which are retransmitted to the Receivers in the region, either via unicast or via subtree- multicast. The SubgroupAuthKey is also used by the entities in a region to group-authenticate control messages that are exchanged with each other. Similar to the GroupAuthKey, we propose the use of IPsec based authentication via keyed hash function. Note that for region-based retransmission of lost packets and for control-packet authentication, the SubgroupAuthKey is used instead of the GroupAuthKey (not both). Note that if a DR happens to be a child within a region and at the same time a parent within its own region, then that DR will hold two distinct SubgroupAuthKeys corresponding to the two regions. In the future, RMTP-II hopes to take advantage of subtree-multicast, where a packet can be sent to a constrained piece of the multicast tree. Ideally, a subtree-multicast only goes to the pieces of the tree that have lost a packet. In this case, additional region keys would have to be distributed, that spanned multiple levels of the hierarchy. We will leave this consideration for a future time, however, since subtree-multicast does not yet exist in a deployable form. - InteriorNodeKey: The InteriorNodeKey is a symmetric key shared by all interior control nodes within a given TRACK hierarchy. The key is independent of any data stream, and is used to authenticate control packets exchanged among the DRs/TN. Should a child-DR request a retransmission of a lost data packet from its parent-DR, then the parent-DR will deliver the (encrypted) lost packet to the child-DR, authenticated using the InteriorNodeKey. Before the child-DR retransmits this lost data packet to its own region, it must first authenticate the packet from the parent-DR using the InteriorNodeKey. It must then use its own SubgroupAuthKey of the region headed/parented by that child-DR to provide authentication for the retransmitted data packet. 6. Limitations The proposed security architecture has certain limitations. These include: (a) Brute Force Attacks. At the transport level, no admission controls can be put in place to throttle a sender which is generating lots of spurious packets to a multicast address. This is the requirement of the network level. At the present time, no accepted standard exists for doing so at the IP Multicast level. (b) Key Corruption. The recommended group key architecture makes a careful tradeoff between the need to distribute many keys, and the need to localize the effects of a node which is compromised. This proposal allows a local receiver to perpetrate denial of service attacks to its local DR, and the receivers served by that DR. (c) Privacy. In order to prevent network traffic analysis attacks, the group keys can be used with IPsec to encrypt the packets sent to the group, in addition to doing packet authentication. However, it must be recognized that this is not a general solution for data privacy. In particular, the group keys can easily be passed from a valid receiver to an unauthorized receiver, to enable piracy of pay-per- use services. This is reasonable, as data privacy is not considered part of the scope of TRACK protocols. (d) Multicast IPsec. Although currently IPsec is generally implemented for pair-wise (one-to-one) communications between one sender and one receiver, the design of IPsec itself allows for usage in IP multicast. Currently the Security Association (SA) definition requires the Security Parameter Index (SPI) to be selected by the receiver [KA98a]. However, since in IP multicast a group address may be associated with multiple receivers, the existing method of selecting the SPI must be re-interpreted. Hence, in the context of "Multicast IPsec", a pre-defined entity (e.g. the source, or the key server/manager) must first create the Group-SA (including selecting the SPI) and deliver the Group-SA to all the members of the group (by either the "push" or "pull" paradigm). Thus rather than being a modification to the IPsec specification, this requirement simply means that additional protocols are needed to establish a shared Group-SA. One possible approach for the Group Key Management (GKM) protocol is to also deliver the Group-SA (and other keying material) to the receiver at the same time it delivers the GroupDataKey [HCM98]. 7. Summary In summary, in the current work we have proposed for TRACK protocols the separation of data stream confidentiality using a symmetric key (i.e. implicit group-authentication) from data authentication using a symmetric key (i.e. explicit group-authentication). Data stream confidentiality using a symmetric key will be conducted at the application layer, while data authentication using a symmetric key will be conducted at the network layer. Since the DRs/TN may be (optionally) prevented from reading the multicast data, two (2) different symmetric keys must be deployed corresponding to the needs of data stream confidentiality and data group-authentication. This proposal follows a number of requirements, some of which are specific to TRACK protocols. The use of group-authentication at the network layer is: - for protection of the transport and IP headers. - to allow a DR to authentically retransmit lost packets to a destination address (unicast or local multicast) different from the original multicast group address. - to allow a separate symmetric key encryption to be applied (at the application layer) in order prevent the DRs/TN from reading the data. We assume encryption for confidentiality (using the GroupDataKey) has been applied above the transport layer by the sender/source, in order to prevent a DR/TN from decrypting the data. The GroupDataKey is only available to the group members, excluding the interior control nodes. We propose the use of another key (GroupAuthKey) to provide group- authentication from the source/sender at the network layer using symmetric key cryptography. The GroupAuthKey is known by the members of the group, as well as the interior control nodes. For the retransmission of lost packets to regions within a group, either via unicast or local multicast, we propose the use of a SubgroupAuthKey (instead of the GroupAuthKey) which is known only to entities within a region (DR and its children). The SubgroupAuthKey is also used by the entities in a region to group-authenticate control messages that are exchanged with each other. 8. References [HCM98] T. Hardjono, B. Cain and I. Monga, "Intra-Domain Group Key Management Protocol", work in progress, draft-ietf-ipsec-intragkm- 00.txt, Nov 1998. [HH99a] H. Harney and E. Harder, "Group Security Association Key Management Protocol", work in progress, draft-harney-sparta-gsakmp-sec- 00.txt, May 1999. [KCWP00] M. Kadansky, D. Chiu, J. Wesley, J. Provino. "Tree-based Reliable Multicast (TRAM)", work in progress, draft-kadansky-tram- 02.txt, January 2000. [KA98a] S. Kent and R. Atkinson, "Security Architecture for the Internet Protocol", IETF, RFC 1825, 1998. [KA98b] S. Kent and R. Atkinson, "IP Authentication Header", work in progress, Internet Draft, July 1998. [MG98a] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", work in progress, draft-ietf-ipsec-auth-hmac-md5-96-03.txt, Feb 1998 [MG98b] C. Madson, R Glenn, The Use of HMAC-SHA-1-96 within ESP and AH", work in progress, "draft-ietf-ipsec-auth-hmac-sha1-96-03.txt, Feb, 1998. [R92] R. Rivest, "MD5 Digest Algorithm", RFC1321, April 1992. [RSA93] RSA Laboratories, "PKCS#1: RSA Encryption Standard", Volume1.5, No. 1993. [WBPM98] B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, "RMTP-II Specification". Work in progress, draft-whetten-rmtp-ii-00.txt, April 8, 1998. --=====================_286204430==_.ALT Content-Type: text/html; charset="us-ascii" Someone reported that the file was corrupted, so it is attached below.
Sorry to add to everyone's mailbox!
Brian


Internet Engineering Task Force                             T. Hardjono
INTERNET-DRAFT                                          Nortel Networks
draft-ietf-rmt-track-security-00.txt                         B. Whetten
January 12, 2000                                               Talarian




             Security Requirements For TRACK Protocols

              <draft-ietf-rmt-track-security-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

This document discusses the security issues within TRee-based
ACKnowledgement (TRACK) reliable multicast protocols, and identifies
some constraints and requirements for security provisions for these
protocols.  Based on the constraints and requirements, the document
proposes a separation of data packet confidentiality and authentication,
from transport layer protection.  It proposes that TRACK protocols be
primarily concerned with group authentication of control and data
packets, to protect against attacks on the transport infrastructure.  It
proposes that data confidentiality and source authentication be provided
separately from this low level group authentication, ideally at the
application level.  We show that this is particularly important for
TRACK protocols, because of the requirement that the interior control
nodes only optionally have access to the data packet payload.

Specifically, the current work proposes that data and control packet
authentication be provided using IPsec-based authentication at the
network layer.  This approach allows an interior control node to
authentically retransmit a lost data packet (which remains encrypted
under the separate data-encryption key) to its own children (a set of
Receivers), while making use of the IPsec features, such as protection
against replay attacks. 

This document then provides a specific proposal for how group keys
should be divided up among group members, for control and data packet
authentication.  While providing some rationale for divorcing this
proposal from that of source authentication and data confidentiality, it
does not provide a specific proposal for those pieces.


1. Background: The Multicast Security Problem

The problem of multicast security can be divided into three general
areas of concern:
- Data Encryption and Source Authentication.  The method used to
encipher or scramble the multicast data, and verify the identity of
the sender of this data.
- Key Distribution.  The method used to securely distribute group
keys and keying material to the members of a group, for use in
decrypting or authenticating the data or control packets.
- Infrastructure protection.  Mechanisms used to protect the
multicast infrastructure itself, and to minimize the ability of an
intruder to deny service to legitimate users.

The security of reliable multicast protocols falls primarily into the
third category of problems.  Complete denial of service protection must
start at the network level (i.e. IP Multicast), with controls placed on
senders from overloading the network with brute force "spamming", as
well as with authentication of control packets, to keep users from
corrupting the state of the IP Multicast protocols.  A transport
protocol needs to address the same issues, checking to make sure that
senders are not sending more data than they are allowed (such as with
enforceable congestion control), and authenticating control packets, to
protect the protocol state.  Control packet authentication is
particularly important in TRACK protocols, because of their use of
interior control nodes (for example, in RMTP-II, DRs and TNs) to
increase scalability.

An optional extension to the requirement of infrastructure protection is
that of infrastructure privacy.  Some applications require that the
headers of the network packets be encrypted, to provide protection from
network analysis attacks.


2. Independence of RM Security

The security of reliable multicast (RM) protocols is part of the larger
problem of the security of the multicast infrastructure, which also
consists of the security of the multicast routing protocols.

Since RM protocols and multicast routing protocols exist at different
layers in the protocol stack, and since different RM protocols may be
employed with different multicast routing protocols, it is useful from a
security perspective to treat these two security problems separately. 
In addition, although in many instances the topology of RM
infrastructure may coincide with that of the multicast routing protocol,
such symmetry cannot be assumed for all cases.

Similarly, from a design perspective, the problem of securing the data
stream (e.g. through content encryption) should be separated from the
issue of securing reliable multicast protocols.

Although we treat RM-security as an independent problem from other
multicast security problems, this does not preclude using the solutions
in other areas in order to solve the security needs of RM. For example,
the use of IPsec technology at the IP layer to authenticate multicast
routing protocol control-packets can also be used to authenticate RM
control-messages.  However, the instance of deploying IPsec in both
cases must be distinguished and treated separately.


3. RMTP-II Overview

While not necessarily typical of all TRACK protocols (such as TRAM
[KCWP00]), we use the RMTP-II protocol as an example for analysis and
discussion.  The RMTP-II protocol features a number of entities which
participate in a logical tree or hierarchy and which exchange control-
messages with each other.  The entities are the Top Node (TN), the
Sender Nodes (SD), the Designated Receiver Nodes (DR) and the Receiver
Nodes (RN). 

RMTP-II places receivers into local regions, where each region is
assigned to a DR.  These groups are arranged hierarchically as a tree
rooted at the TN, with the DRs representing the nodes of the tree, and
the receivers as the leaves.  The senders connect directly to the top
node, at the top layer of the hierarchy.  The receivers send their
control-messages (ACKs, NACKs, etc.) to the DR of their region. 
Retransmission of lost packets may be done locally by the DR of a
domain, or globally from the sender.  Each DR sends their control
messages to the DR at the next level up the hierarchy.  This process is
repeated until the TN, who then forwards the control messages to the
appropriate sender.  The DRs and TN aggregate the positive
acknowledgements from the receivers, and suppress the redundant negative
acknowledgements, in order to solve the ACK/NACK implosion problem.

A DR maintains a local multicast group to just its children, and
subscribes to the local multicast group of its parent.  A DR uses this
local multicast group for retransmissions to its children.  While RMTP-
II uses multicast for retransmission from a DR, other TRACK protocols
may choose to optionally use unicast.

RMTP-II distinguishes between a data channel and a control channel.  A
data channel is a global multicast group created using the underlying
multicast routing protocol.  A control channel is the interconnected
topology of control nodes, for handling error recovery and positive
packet acknowledgements.

In order to obtain data packets from the Sender, a Receiver in a given
RMTP-II region must join the multicast group (i.e. the data channel). 
The DR of that region must join every multicast group that its
descendants have joined.  Note that the DRs are not responsible for
forwarding the data packets multicast by the Sender, since that data
stream is propagated by the underlying multicast routing protocol.

The figure below illustrates an RMTP-II tree with multiple control
nodes.

                                          HACKs
              -----------> (Top Node)----------------->(Sender node)
             ^                ^^^                             |
             |              /  |  \                           |
       HACKs |            /    |    \                         |
             |          /      |      \                       |
             |        /        |        \     (Designated     |
                    /          |          \    Receiver       |
                  /            |            \   node)         v
      Control   D R           D R           D R  <------------|
      Channel   ^^            ^^^            ^^               | Data
               / |           / | \           | \              | Channel
              /  |          /  |  \          |  \             |
             /   |         /   |   \         |   \            v
           RN   RN       RN   RN   RN        RN   RN   <------
                       (Receiver Nodes)



4. TRACK Protocol Security Issues and Requirements

This section details the security requirements for TRACK protocols which
are similar to RMTP-II.  These requirements include general multicast
transport requirements, as well as some requirements specific to TRACK
protocols.

4.1 Background

In addressing the security issues specific to TRACK protocols, it is
useful to consider the general aspects of security relating to reliable
multicast.

 - Layer in which security is applied:
The two layers in which security mechanisms are deployed are
typically the network layer and the application layer.  In the
network layer the protocol that is the most commonly used is the
IPsec protocol, which provides authentication and/or encryption.  In
either case, with IPsec the transport headers (and IP headers) are
protected.  When authentication and/or encryption is applied at the
application layer, neither the transport headers nor the IP headers
are protected.

 - Types of authentication:
  - Source-authentication: If public key (asymmetric) cryptography is
deployed, where only the sender knows the secret-half of the
public key pair, then unique "source-authentication" can be
established.
  - Group-authentication: If shared key (symmetric) cryptography is
deployed and the key is shared by more than two parties, then
only "group-authentication" can be established. This means that a
receiver in a group is only certain that the entity that sent the
message is in possession of the symmetric-key, and is thus
assumed to be a member of the group sharing the key.

In the following, the TRACK specific requirements are further
elaborated.


4.2 Authentication of Control-Messages

As stated above, the directly relevant security concern for TRACK
protocols is protection of the multicast infrastructure, particularly of
the control tree, in order to provide protection against replay or other
attacks which seek to corrupt the state of the transport protocol.  The
authentication of control messages exchanged among TRACK protocol
entities represents the minimal security mechanisms necessary to do so.

Two types of authentication mechanisms can be adopted, corresponding to
the two basic types of cryptosystems.  In the context of reliable
multicast, throughput and latency is typically of high importance, and
group-authentication based on symmetric cryptography appears to be
preferable. 

Given this, the efficiencies of symmetric key based authentication
appear to outweigh the benefits of public key based authentication.
There are potentially cryptographic schemes that can provide the unique
source-authentication of public key cryptography while providing the
performance characteristics of symmetric key based authentication (e.g.
efficient digital signing of the hash-value of several data packets). 
However, at the present time, for the general case of infrastructure
protection, the complexities of these options appear to outweigh the
benefits.

Thus, in summary, for TRACK protocol control-messages, explicit group-
authentication at the IP layer should be deployed using symmetric
cryptography.  Although a number of technologies are available, we
propose specifically IPsec-based authentication using a keyed-hash
function [KA98b,MG98a,MG98b] due to its growing use and availability.

We denote the symmetric key used for control message authentication as
the InteriorNodeKey. The InteriorNodeKey is a symmetric key shared by
all DRs and the TN within a given RMTP-II or TRACK hierarchy.  The key
is independent of any data stream, and is used to authenticate control
packets exchanged among the DRs/TN. 


4.3 Non-Decipherability of Data Packets by DRs

RMTP-II requires that a Designated Receiver Node (DR) join all of the
multicast groups that its descendants have joined.  This is also true of
the Top Node (TN).

For TRACK protocols it is preferable that authentication methods based
on a symmetric key be deployed due to performance reasons.  This may be
achieved explicitly, such as by using a keyed hash function, or
implicitly using encryption (where a successful decryption implies the
ciphertext is both unmodified in transit and was generated by a holder
of the symmetric key).

However, TRACK protocols have a further requirement, namely that their
repair nodes (i.e. DR and TN) be (optionally) prevented from reading the
multicast data. More specifically, we perceive that DRs may be
administered as part of a reliability service offered by third parties
such as ISPs.  These third parties may refuse the ability to decipher
data packets in order to avoid the legal ramifications of having access
to the data contents.  Thus, from the ISP perspective, TRACK protocols
must allow them to prove to the content-owner that they do not posses
the means to alter the contents transmitted through the multicast
groups.

Given the above requirement of the DRs/TN and the need for fast
authentication, we propose:

- the separation of data stream confidentiality using either a symmetric
or asymmetric key from data authentication using a symmetric key (i.e.
explicit group-authentication).

- data stream confidentiality will be conducted at the application
layer, while data authentication using a symmetric key will be
conducted at the network layer.

- since the DRs/TN may be (optionally) prevented from reading the
multicast data, two (2) different keys must be deployed corresponding
to the needs of data stream confidentiality and data group-
authentication.


4.4 Authentication of Data Retransmissions

In TRACK protocols, retransmissions of data packets may come from the
original source, or from a different (DR) node.  This local recovery is
an important tool for increasing the scalability and latency of a
protocol.  In the context of security, it raises the question as to what
authentication methods should be used on these packets.

(a) If source authentication (using public key cryptography) and data
confidentiality (including implicit group authentication) is
applied at the application layer, the DR can simply replay the data
(i.e. payload) unmodified to the querying receivers, either via
unicast or local multicast.

(b) If, however, explicit group authentication (using a symmetric key)
was applied at the network layer (e.g. using IPsec), then the DR
cannot simply replay the packet due to restrictions at the IP
layer.  Thus, in this case the DR must re-apply the group-
authentication.

Taking case (b) further, there are two options corresponding to
whether retransmission by the DR is performed via unicast to a
receiver or via multicast.

(i) If the retransmission is unicast to a given receiver, then it
is preferred if the DR and the receiver share a separate
symmetric key for this purpose.

(ii) If the retransmission is via multicast to a subgroup (as is
the case in RMTP-II), then the DR can either use the existing
group-shared symmetric key or use a separate symmetric key only
for the subgroup under the DR.  We propose to use the later
approach, which means that a DR and its children (receivers)
must share a separate symmetric key for explicit group
authentication at the IP layer.


4.5 Keys for Data Confidentiality and for Authentication

As mentioned above, we propose the separation of data stream
confidentiality using a symmetric key encryption (effecting an implicit
group-authentication) from data authentication using a symmetric key and
a keyed hash function (i.e. explicit group-authentication).

We now denote the symmetric key for data stream confidentiality at the
application layer as the GroupDataKey. Only the source and valid
receivers will have a copy of the GroupDataKey, which is delivered to
them through the appropriate Group Key Management (GKM) protocol that
identifies and verifies the members individually.  In the case where the
DRs and the TN are not permitted to read the multicast data, they must
be prevented by the GKM protocol from obtaining the GroupDataKey.

We denote the symmetric key for explicit group-authentication at the
network layer as the GroupAuthKey. The GroupAuthKey is distinct from the
GroupDataKey. For TRACK protocols, we propose the use of IPsec with
keyed hashing at the network layer to provide explicit group-
authentication using the GroupAuthKey.  Unlike the GroupDataKey, the
GroupAuthKey is known by all entities involved in the multicast.  This
includes all interior node entities (e.g. TN, DR), the Sender/Source and
the Receivers.


4.6 Authenticity of NACK and other Control Packets

In TRACK protocols, a DR responds to a NACK from one its children
(typically a receiver) by re-transmitting the lost packet via local
multicast.  This basic behavior can be open to abuse by an attacker who
injects spurious NACK messages towards the DR, effecting a local
multicast to all children of the DR.  In itself this is a waste of
bandwidth and may result in a denial of resource to the group members. 
Other control packets directly impact the state of the group, such as
the group membership, and could also be used in denial of service
attacks.

To counter these types of attack, the control messages themselves must
be authenticated by the DR.  Digital signatures using public key
cryptography could be applied to the control messages.  However, this
approach would be inefficient due to the high CPU cost of public key
encryption.  Also, it would require creating a separate security
association with each child of the DR.

Instead, we propose that NACK and other control messages from a child
(receiver) to its DR be protected using symmetric IPsec based
authentication.  This requires the two parties to first establish a
Security Association (SA) and a shared symmetric key.  The symmetric key
can be unique per child, or be uniform over a subgroup of receivers
(i.e. those under the DR).


4.7 Fault Recovery

In RMTP-II, if a child's connection to a DR or TN fails, RMTP-II
provides automatic mechanisms for failing-over to another DR or backup
TN.  This reconnection needs to happen quickly, so that the child can
rejoin the data stream before too much data has been missed to recover
from.  If a child needs to get a new key for that DR/TN, this can be a
bottleneck.  Given that the key distribution infrastructure may be
centralized, and a majority of receivers may need to fail over at the
same time, this presents a major opportunity for network congestion.

The RMTP-II entities are given the address of their backup control node
at startup time.  While these addresses can change, they are expected to
always have the addresses of one or more backup nodes.  When
implementing security features, each child should be required to keep
the key for its primary backup DR/TN.  Optionally, it may need to keep
the keys for each of the backup control nodes it is using.


4.8 Implementation with Different Levels of OS Protection

A TRACK protocol can be implemented in (at least) one of three ways.
- Application level.  Most implementations of TRACK protocols for the
near future are expected to operate in the application level of the
OS, running on top of UDP.
- Kernel.  As TRACK protocols become bundled with standard operating
systems, it is expected to become a kernel module, and run directly
over IP.
- Virtual machine.  Some TRACK entities (particularly senders and
receivers) will be run in virtual machines, such as when implemented
as a Java applet.

TRACK protocol security must accommodate all three of these options. 
This raises the following issues.
- Application Level.  One advantage of application level
implementations is their flexibility.  These implementations could
use either IPsec routines, the application layer security functions,
or both.
- Virtual Machines.  There are issues trying to use IPsec with
virtual machines such as Java, which have to date hindered the
support of IPsec through native Java applets.  This makes it
important for a TRACK protocol to optionally be able to use only
application level security.
- Kernel Implementations.  As a TRACK protocol becomes bundled with
operating systems, it is expected that IPsec will also become bundled
with the OS.  To avoid having to use less trusted software in the
application level, the TRACK protocol will have to be able to use a
kernel level security system (such as IPsec) for its transport level
security needs.


4.9 Separate Regional Protection

TRACK protocols are expected to be used for content distribution from a
few senders to many receivers.  In the case of applications that
distribute critical data to many different organizations, it is not
enough to trust all receivers.  For example, a market data feed provider
could be using a TRACK protocol to distribute live market data feeds to
competing financial institutions.  In this situation, the data feed
provider needs to be able to protect individual companies from corrupted
control packets from other customers (which could be generated either
intentionally, or more likely, unintentionally) which would cause denial
of service.

As we propose in the next section, a TRACK protocol must provide
separate regional keys for the group-authentication of control packets
sent from the receivers of different DRs.  This allows the
authentication of control-messages for each set of receivers (part of
one customer) to be done separately (from another set of receivers, as
part of different customer). Since for each set of receivers a different
key is used, this limits the ability of a customer to perpetrate denial
of service attacks against other customers.


4.10 Piracy of Pay-Per-Use Data

A common scenario for TRACK protocols involves pay-per-use data
distribution, such as live market data, pay-per-view video signals, or
paid subscriptions to software updates.  In this scenario, a receiver
cannot be trusted to not give its group keys to outside entities, who
are trying to get free service.  We mention this requirement since it is
different than point-to-point security.  However, this requirement is
the responsibility of the application level security.



5. Architecture Recommendations

The previous section detailed some of the specific requirements and
issues for TRACK protocol security, along with some individual
recommendation on handling each one.  Given those requirements, we
propose the following architecture recommendations for implementing
security with TRACK protocols. 


5.1 Separation of Security Responsibilities

As detailed above, TRACK protocols are primarily concerned with
protection of the network infrastructure, rather than with issues such
as data confidentiality and source-authentication.  Therefore, we
recommend that TRACK protocols SHOULD provide:
   (a) group authentication of control packets, and
   (b) optional group authentication of data packets
Optionally, TRACK protocols MAY choose to provide:
   (c) optional privacy of data and of control packet headers. 
To accomplish this, we recommend that TRACK protocols use IPsec
technology at the network layer, while letting application level
security perform additional functions as needed.  For implementations
that do not have access to IPsec, and are not implemented as part of the
OS, application level security can be used instead--although this of
course risks incompatibility with other implementations.

The separation of group-authentication of data from both data source-
authentication and data-confidentiality is tightly coupled to the choice
of recommending IPsec for the group authentication.  These two choices
are motivated by the following:

(a) Non-Decipherability of data by interior control nodes: it is a
requirement of TRACK protocols that in some deployments, its control
entities (e.g. TN, DR) be unable to decipher the data packet.  Thus,
the GroupDataKey for data encryption and GroupAuthKey for group-
authentication must be distinct.  It is not sufficient to simply use
an identical key (for the GroupDataKey and GroupAuthKey) and to
instruct the TRACK protocol entities to avoid deciphering the data
packets.  It must be provably shown that the interior control nodes
do not have the ability to decipher the data packets (even if they
wish to do so).

(b) Use of IPsec technologies: considerable effort has been invested in
developing the IPsec architecture and protocols [KA98a, KA98b], and
a growing number of vendors are supporting IPsec.  The IPsec suite
offers a number of features, including some protection against
replay attacks.

(c) Multicast IPsec: the IPsec architecture has intentionally allowed
the use of IPsec for IP multicast without changes to the basic
constructs within the IPsec suite.  Currently, work is proceeding
towards the establishment of a standard mechanism to select the
Group Security Association (Group SA or GSA) for multicast and a
method to disseminate the GSA to the valid members of the group
[HCM98,HH99a].

(d) Appropriate Level:  since the primary purpose of transport level
security is to secure the infrastructure at a transport level, using
a network or transport level security protocol allows each to be
implemented together--either in the OS, or in the application layer.


5.2 Division of Responsibilities

Given this fundamental division between application and transport
responsibilities, we divide the security responsibilities in to four
parts.

Network Responsibilities (IP and IP Multicast)
----------------------------------------------

- Admission controls on senders--to protect against "brute
  force" spamming attacks.
- Authentication of routing control packets--to protect
  the routing infrastructure from denial of service attacks.

Transport Responsibilities (TRACK Protocols)
------------------------------------
- Protection of the control messages from replay attacks
  and other denial-of-service attacks.
- Optional: protection of data packets from replay attacks.
- Optional: encryption of control messages to minimize
  network analysis by attackers.

End to End Responsibilities (Application)
-----------------------------------------
- Source authentication--to verify the authenticity of data,
  and provide optional non-repudiation of data.
- Data encryption--to provide data confidentiality.

Key Management Infrastructure
-------------------------------
- Distribution of transport and network layer keys: authentication
  of individual hosts, and distribution of keys to those hosts
- Application level key distribution: authentication of
  individual processes, and distribution of keys to those processes
- Optional: periodic rekeying--group keys periodically need
  to be changed, both after a certain time limit has expired,
  and/or after the group membership changes.

The figure below shows how these components relate to each other.  TRACK
protocols can be used without any additional security at the IP/IP
Multicast level, although this will not provide full protection from
denial of service attacks.  TRACK protocols will be able to be used on
top of UDP or raw IP/IP Multicast.  A TRACK protocol can use either
IPsec or application level security for its network security
requirements, although we recommend using IPsec wherever possible.
                       +--------------------+       +----------+
+--------------+<----->|    Application     |<----->|  App Sec |
|              |       +--------------------+   |==>|          |
|              |       |       TRACK        |<--|   +----------+
|     Key      |<----->+          +---------+   |-->|          |
|  Management  |       |          |   UDP   |       |   IPsec  |
|              |       +--------------------+       |          |
|              |<=====>|  IP, IP Multicast  |<=====>|          |
+--------------+       +--------------------+       +----------|

  <===> Optional


When a data packet is to be sent to the multicast group, the
Sender/Source first (optionally) enciphers the data packet using the
GroupDataKey above the RM/transport layer.  It is then passed to the
RM/transport layer, which attaches the necessary RM headers.  The result
is then passed down to the IP layer where IPsec authentication is
established (using the GroupAuthKey).

A Receiver in the multicast group would be in possession of both the
GroupDataKey and the GroupAuthKey, and thus will be able to first
authenticate the data packet using the GroupAuthKey, and then continue
to decipher the data packet using the GroupDataKey.

A Designated Receiver Node (DR) will possess the GroupAuthKey (but not
the GroupDataKey), and thus will only be able to authenticate the packet
using the GroupAuthKey using IPsec.  After verifying the authenticity of
a received data packet, a DR will be able to retransmit the (enciphered)
data packet to its children, either via unicast or region-based local
multicast.  A retransmission of a lost data packet from a DR will be
authenticated using a SubgroupAuthKey (see below) which is a symmetric
key shared by a DR and all its children Receivers only.

Again, although the current work proposes the use of unicast IPsec and
multicast IPsec at the network layer, it does not preclude the use of
other authentication technologies at the network layer or at the
RM/transport layer.  Such technologies, however, will have to address
much of the same issues faced by IPsec, including prevention of replays,
the creation and maintenance of state (i.e. "Security Associations")
associated with the GroupAuthKey, the Sender and Receiver(s), and other
features and supporting mechanisms.  It is precisely the growing
availability of IPsec that motivates the current work to choose IPsec
for network layer authentication for both data and control packets.


5.3 TRACK Keys

In general, each node in the hierarchy must be able to authenticate
itself to the key management entity/server, before it will be allowed to
receive any of the below keys.  We assume the implementation of a key
management infrastructure, which interfaces with the DRs and TNs, as
well as the senders and receivers. 

We propose that this key management system be responsible for
distributing the following TRACK protocol keys:

 -  GroupDataKey:
The GroupDataKey is the unique symmetric key for data encryption
shared by all members of a multicast group, excluding the interior
tree entities.  Typically, one GroupDataKey is associated with one
multicast group.  The GroupDataKey is used to provide access control
to the data packet by way of the Sender/Source enciphering the data
packet.  Since only the Receivers hold the copy of the GroupDataKey,
only the Receivers will be able to decipher the data packets.  This
is an optional key, which does not directly concern the TRACK
transport.

 -  GroupAuthKey:
The GroupAuthKey is the unique symmetric key shared by all members
of a multicast group, including the interior control nodes.  One
GroupAuthKey is associated with one multicast group.  The purpose of
the GroupAuthKey is to provide authentication of the (possibly
enciphered) data packets.  In the context of IPsec authentication,
this can be achieved using a keyed hash function, such as HMAC-MD5-
96 [MG98a] and HMAC-SHA-1-96 [MG98b].

 -  SubgroupAuthKey:
The SubgroupAuthKey is the unique symmetric key shared only by
entities within a given local region, consisting of a DR and its
children (consisting of one or more Receivers, and possibly one
child DR). The SubgroupAuthKey is used by the parent in a local
region to provide group-authentication for the (lost) data packets
(still enciphered under the GroupDataKey) which are retransmitted to
the Receivers in the region, either via unicast or via subtree-
multicast.  The SubgroupAuthKey is also used by the entities in a
region to group-authenticate control messages that are exchanged
with each other. Similar to the GroupAuthKey, we propose the use of
IPsec based authentication via keyed hash function.

Note that for region-based retransmission of lost packets and for
control-packet authentication, the SubgroupAuthKey is used instead
of the GroupAuthKey (not both).

Note that if a DR happens to be a child within a region and at the
same time a parent within its own region, then that DR will hold two
distinct SubgroupAuthKeys corresponding to the two regions.

In the future, RMTP-II hopes to take advantage of subtree-multicast,
where a packet can be sent to a constrained piece of the multicast
tree.  Ideally, a subtree-multicast only goes to the pieces of the
tree that have lost a packet.  In this case, additional region keys
would have to be distributed, that spanned multiple levels of the
hierarchy.  We will leave this consideration for a future time,
however, since subtree-multicast does not yet exist in a deployable
form.

 -  InteriorNodeKey:
The InteriorNodeKey is a symmetric key shared by all interior
control nodes within a given TRACK hierarchy.  The key is
independent of any data stream, and is used to authenticate control
packets exchanged among the DRs/TN.  Should a child-DR request a
retransmission of a lost data packet from its parent-DR, then the
parent-DR will deliver the (encrypted) lost packet to the child-DR,
authenticated using the InteriorNodeKey.

Before the child-DR retransmits this lost data packet to its own
region, it must first authenticate the packet from the parent-DR
using the InteriorNodeKey.  It must then use its own SubgroupAuthKey
of the region headed/parented by that child-DR to provide
authentication for the retransmitted data packet. 


6. Limitations

The proposed security architecture has certain limitations.  These
include:

(a) Brute Force Attacks.  At the transport level, no admission controls
can be put in place to throttle a sender which is generating lots of
spurious packets to a multicast address.  This is the requirement of
the network level.  At the present time, no accepted standard exists
for doing so at the IP Multicast level.

(b) Key Corruption.  The recommended group key architecture makes a
careful tradeoff between the need to distribute many keys, and the
need to localize the effects of a node which is compromised. This
proposal allows a local receiver to perpetrate denial of service
attacks to its local DR, and the receivers served by that DR.

(c) Privacy.  In order to prevent network traffic analysis attacks, the
group keys can be used with IPsec to encrypt the packets sent to the
group, in addition to doing packet authentication.  However, it must
be recognized that this is not a general solution for data privacy. 
In particular, the group keys can easily be passed from a valid
receiver to an unauthorized receiver, to enable piracy of pay-per-
use services.  This is reasonable, as data privacy is not considered
part of the scope of TRACK protocols.

(d) Multicast IPsec.  Although currently IPsec is generally implemented
for pair-wise (one-to-one) communications between one sender and one
receiver, the design of IPsec itself allows for usage in IP
multicast.  Currently the Security Association (SA) definition
requires the Security Parameter Index (SPI) to be selected by the
receiver [KA98a].  However, since in IP multicast a group address
may be associated with multiple receivers, the existing method of
selecting the SPI must be re-interpreted.  Hence, in the context of
"Multicast IPsec", a pre-defined entity (e.g. the source, or the key
server/manager) must first create the Group-SA (including selecting
the SPI) and deliver the Group-SA to all the members of the group
(by either the "push" or "pull" paradigm).  Thus rather than being a
modification to the IPsec specification, this requirement simply
means that additional protocols are needed to establish a shared
Group-SA.  One possible approach for the Group Key Management (GKM)
protocol is to also deliver the Group-SA (and other keying material)
to the receiver at the same time it delivers the GroupDataKey
[HCM98].


7. Summary

In summary, in the current work we have proposed for TRACK protocols the
separation of data stream confidentiality using a symmetric key (i.e.
implicit group-authentication) from data authentication using a
symmetric key (i.e. explicit group-authentication). Data stream
confidentiality using a symmetric key will be conducted at the
application layer, while data authentication using a symmetric key will
be conducted at the network layer.  Since the DRs/TN may be (optionally)
prevented from reading the multicast data, two (2) different symmetric
keys must be deployed corresponding to the needs of data stream
confidentiality and data group-authentication.

This proposal follows a number of requirements, some of which are
specific to TRACK protocols.  The use of group-authentication at the
network layer is:
   - for protection of the transport and IP headers.
   - to allow a DR to authentically retransmit lost packets to
     a destination address (unicast or local multicast) different
     from the original multicast group address.
   - to allow a separate symmetric key encryption to be applied
     (at the application layer) in order prevent the DRs/TN from
     reading the data.

We assume encryption for confidentiality (using the GroupDataKey) has
been applied above the transport layer by the sender/source, in order to
prevent a DR/TN from decrypting the data.  The GroupDataKey is only
available to the group members, excluding the interior control nodes.

We propose the use of another key (GroupAuthKey) to provide group-
authentication from the source/sender at the network layer using
symmetric key cryptography.  The GroupAuthKey is known by the members of
the group, as well as the interior control nodes.

For the retransmission of lost packets to regions within a group, either
via unicast or local multicast, we propose the use of a SubgroupAuthKey
(instead of the GroupAuthKey) which is known only to entities within a
region (DR and its children). The SubgroupAuthKey is also used by the
entities in a region to group-authenticate control messages that are
exchanged with each other.


8. References

[HCM98] T. Hardjono, B. Cain and I. Monga, "Intra-Domain Group Key
Management Protocol", work in progress, draft-ietf-ipsec-intragkm-
00.txt, Nov 1998.

[HH99a] H. Harney and E. Harder, "Group Security Association Key
Management Protocol", work in progress, draft-harney-sparta-gsakmp-sec-
00.txt, May 1999.

[KCWP00] M. Kadansky, D. Chiu, J. Wesley, J. Provino.  "Tree-based
Reliable Multicast (TRAM)", work in progress, draft-kadansky-tram-
02.txt, January 2000.

[KA98a] S. Kent and R. Atkinson, "Security Architecture for the Internet
Protocol", IETF, RFC 1825, 1998.

[KA98b] S. Kent and R. Atkinson, "IP Authentication Header", work in
progress, Internet Draft, July 1998.

[MG98a] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH",
work in progress, draft-ietf-ipsec-auth-hmac-md5-96-03.txt, Feb 1998

[MG98b] C. Madson, R Glenn, The Use of HMAC-SHA-1-96 within ESP and AH",
work in progress, "draft-ietf-ipsec-auth-hmac-sha1-96-03.txt, Feb, 1998.

[R92] R. Rivest, "MD5 Digest Algorithm", RFC1321, April 1992.

[RSA93]  RSA Laboratories, "PKCS#1: RSA Encryption Standard", Volume1.5,
No. 1993.

[WBPM98] B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, "RMTP-II
Specification".  Work in progress, draft-whetten-rmtp-ii-00.txt, April
8, 1998.



--=====================_286204430==_.ALT-- From owner-rmt@listserv.lbl.gov Tue Feb 15 20:36:02 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00082 for ; Tue, 15 Feb 2000 20:35:59 -0500 (EST) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id PAA21877; Tue, 15 Feb 2000 15:36:46 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA21873 for ; Tue, 15 Feb 2000 15:36:44 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA24618 for ; Tue, 15 Feb 2000 15:36:43 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA24577 for ; Tue, 15 Feb 2000 15:36:38 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id QAA11669 for ; Tue, 15 Feb 2000 16:36:35 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA29203 for ; Tue, 15 Feb 2000 16:36:29 -0700 (MST)] Received: from arc.corp.mot.com (t-il06-x-port9.corp.mot.com [129.188.170.119]) by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id KAA27954 for ; Wed, 16 Feb 2000 10:34:59 +1100 (EST) Message-ID: <38A9E54C.C5B94058@arc.corp.mot.com> Date: Wed, 16 Feb 2000 10:46:20 +1100 From: Roger Kermode Reply-To: Roger.Kermode@motorola.com Organization: Motorola X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rmt-list Subject: Thank you... Content-Type: multipart/mixed; boundary="------------F4B72D15639A2536D677AC53" Sender: owner-rmt@lbl.gov Precedence: bulk This is a multi-part message in MIME format. --------------F4B72D15639A2536D677AC53 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear RMT'ers, thank you all for contributing so much last Thursday. Your efforts were greatly appreciated. The minutes should be out shortly once I've received all the various bits from the scribes and glued them together. One reminder from now on could we please use the subject prefixes below for emails sent to the rmt-list. FEC TREE ALC NACK CONG_{SR,MR} TRACK GRA GUIDE e.g. Subject "TREE: Table of contents" Cheers, Roger --------------F4B72D15639A2536D677AC53 Content-Type: text/x-vcard; charset=us-ascii; name="rkermode.vcf" Content-Description: Card for Roger Kermode Content-Disposition: attachment; filename="rkermode.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Kermode;Roger tel;cell:+61-408-212-284 tel;fax:+61-2-9666-0501 tel;home:+61-2-9664-8335 tel;work:+61-2-9666-0558 x-mozilla-html:FALSE -mozilla-cpt:;0;;; url:www.mot.com.au org:Motorola Australian Research Centre;Scalable Commodity Internet Lab version:2.1 email;internet:Roger.Kermode@motorola.com title:Principal Research Engineer adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A= x-mozilla-cpt:;0 fn:Roger Kermode end:vcard --------------F4B72D15639A2536D677AC53-- From owner-rmt@listserv.lbl.gov Wed Feb 16 05:22:45 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21597 for ; Wed, 16 Feb 2000 05:22:42 -0500 (EST) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA22622; Wed, 16 Feb 2000 01:39:36 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA22618 for ; Wed, 16 Feb 2000 01:39:33 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA09312 for ; Wed, 16 Feb 2000 01:39:32 -0800 (PST) Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA09308 for ; Wed, 16 Feb 2000 01:39:30 -0800 (PST) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id KAA69380; Wed, 16 Feb 2000 10:39:23 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200002160939.KAA69380@info.iet.unipi.it> Subject: pgm web page in place To: rm@mash.cs.berkeley.edu Date: Wed, 16 Feb 2000 10:39:23 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Content-Transfer-Encoding: 7bit [To: rm list, Bcc: rmt list] Just a brief note to inform you that i have put in place the web page containing with a TCP-friendly congestion-controlled PGM implementation (source code, a bootable PicoBSD floppy with lots of good stuff on it so you can actually run it, and a report describing the work). http://www.iet.unipi.it/~luigi/pgm.html cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- From owner-rmt@listserv.lbl.gov Thu Feb 24 05:35:23 2000 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.7.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25381 for ; Thu, 24 Feb 2000 05:35:22 -0500 (EST) Received: (from majordom@localhost) by listserv.lbl.gov (8.9.3/8.9.3) id BAA23450; Thu, 24 Feb 2000 01:28:59 -0800 (PST) X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA23446 for ; Thu, 24 Feb 2000 01:28:57 -0800 (PST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA10879 for ; Thu, 24 Feb 2000 01:28:56 -0800 (PST) Received: from pi4.informatik.uni-mannheim.de (root@pi4.informatik.uni-mannheim.de [134.155.48.96]) by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA10869 for ; Thu, 24 Feb 2000 01:28:55 -0800 (PST) Received: from pi4.informatik.uni-mannheim.de (mauve@pi4 [134.155.48.96]) by pi4.informatik.uni-mannheim.de (8.9.3/8.9.3) with ESMTP id KAA20015; Thu, 24 Feb 2000 10:28:46 +0100 (MET) Message-ID: <38B4F9CE.17C28427@pi4.informatik.uni-mannheim.de> Date: Thu, 24 Feb 2000 10:28:46 +0100 From: Martin Mauve Organization: University of Mannheim X-Mailer: Mozilla 4.08 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: rem-conf@es.net, rmt@lbl.gov Subject: RTP/I Internet Draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rmt@lbl.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, please excuse if this mail is slightly off topic. We have submitted an Internet Draft specifying a Real Time Application Level Protocol for Distributed Interactive Media (RTP/I). Here is the abstract of the RTP/I Internet Draft: This document specifies RTP/I, an application level real-time protocol for distributed interactive media. Typical examples of distributed interactive media are shared whiteboards, networked computer games and distributed virtual environments. RTP/I defines a standardized framing for the transmission of data and provides mechanisms that are universally needed for this media class. Thereby RTP/I enables the development of reusable functionality and generic services that can be employed for multiple distributed interactive media. Examples for this kind of functionality are the ability to record sessions, to support late coming participants, and to provide security services. RTP/I is a protocol that follows the ideas of application level framing and integrated layer processing. It has been designed to be independent of the underlying network and transport layers. To a large extend RTP/I has been inspired by the real-time transport protocol (RTP), which is used for continuous non-interactive media. This document is intended to stimulate the discussion on how to transport distributed interactive media over the Internet. There exists an RTP/I mailing list. Instructions on how to subscribe to this list can be found at the RTP/I homepage (http://www.informatik.uni-mannheim.de/informatik/pi4/projects/RTPI/index.html). Feedback on this document should be addressed to the RTP/I mailing list or directly to the authors. The RTP/I Internet Draft can be downloaded from the IETF directory or from our RTP/I homepage (see above for the URL). We would welcome any kind of feedback! cheers, Martin -- --------------------------------------------------------------------------- Martin Mauve University of Mannheim Praktische Informatik IV Phone: +49-621-181-2616 L 15,16 Fax : +49-621-181-2601 68131 Mannheim mauve@pi4.informatik.uni-mannheim.de Germany ---------------------------------------------------------------------------