From fgont at si6networks.com Mon Sep 5 05:53:36 2011 From: fgont at si6networks.com (Fernando Gont) Date: Mon, 05 Sep 2011 00:53:36 -0300 Subject: [ipv6-wg] More on IPv6 RA-Guard evasion (IPv6 security) Message-ID: <4E6447C0.80701@si6networks.com> Folks, A few months ago I had published a couple of IETF Internet-Drafts to tackle the problem of RA-Guard evasion -- A summary of the problem and pointers to relevant materials is available at: http://blog.si6networks.com/2011/09/router-advertisement-guard-ra-guard.html The two I-Ds are: * http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt * http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-01.txt The former one explains the different attack vectors, and proposes operational counter-measures. The latter proposes a longer-term solution. I'm planning to revise these two I-Ds soon, so any comments/feedback/discussion would be really welcome. P.S.: In case you haven't, you may want to join the IPv6 Hackers mailing-list: http://www.si6networks.com/community/mailing-lists.html Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com web: http://www.si6networks.com From gvandeve at cisco.com Mon Sep 5 10:12:41 2011 From: gvandeve at cisco.com (Gunter Van de Velde (gvandeve)) Date: Mon, 5 Sep 2011 10:12:41 +0200 Subject: [ipv6-wg] More on IPv6 RA-Guard evasion (IPv6 security) In-Reply-To: <4E6447C0.80701@si6networks.com> References: <4E6447C0.80701@si6networks.com> Message-ID: <4269EA985EACD24987D82DAE2FEC62E50440FD02@XMB-AMS-101.cisco.com> Hi Fernando, I gave you my feedback and some advice during the IETF in Quebec in a 1-2-1 email. My hopes are that you integrate the feedback. The draft RA-Guard is correct and needs no fixing. I agree that my security section in the RA-Guard RFC is a bit light on content. However the main thing is that implementations for RA-Guard use traditional ACLs for achieving the goal and then ofcours these implementations can be bypassed with well known and documented ACL's bypass techniques. You can keep rambling the kettle here, but keep the above in mind if you desire to proceed with this work. G/ -----Original Message----- From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf Of Fernando Gont Sent: 05 September 2011 05:54 To: ipv6-wg at ripe.net Subject: [ipv6-wg] More on IPv6 RA-Guard evasion (IPv6 security) Folks, A few months ago I had published a couple of IETF Internet-Drafts to tackle the problem of RA-Guard evasion -- A summary of the problem and pointers to relevant materials is available at: http://blog.si6networks.com/2011/09/router-advertisement-guard-ra-guard. html The two I-Ds are: * http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt * http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-01.txt The former one explains the different attack vectors, and proposes operational counter-measures. The latter proposes a longer-term solution. I'm planning to revise these two I-Ds soon, so any comments/feedback/discussion would be really welcome. P.S.: In case you haven't, you may want to join the IPv6 Hackers mailing-list: http://www.si6networks.com/community/mailing-lists.html Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com web: http://www.si6networks.com From fgont at si6networks.com Tue Sep 6 03:23:17 2011 From: fgont at si6networks.com (Fernando Gont) Date: Mon, 05 Sep 2011 22:23:17 -0300 Subject: [ipv6-wg] More on IPv6 RA-Guard evasion (IPv6 security) In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E50440FD02@XMB-AMS-101.cisco.com> References: <4E6447C0.80701@si6networks.com> <4269EA985EACD24987D82DAE2FEC62E50440FD02@XMB-AMS-101.cisco.com> Message-ID: <4E657605.40104@si6networks.com> Hi, Gunter, On 09/05/2011 05:12 AM, Gunter Van de Velde (gvandeve) wrote: > I gave you my feedback and some advice during the IETF in Quebec in a > 1-2-1 email. > My hopes are that you integrate the feedback. Yes. I'll revise the I-D as proposed. > The draft RA-Guard is correct and needs no fixing. Do you mean the RA-Guard RFC, or my RA-Guard evasion I-D? > I agree that my security section in the RA-Guard RFC > is a bit light on content. However the main thing is that > implementations for RA-Guard use traditional ACLs for achieving the goal > and then ofcours these implementations can be bypassed with well known > and documented ACL's bypass techniques. My I-D is not meant to trash any others' work -- sorry if it came across like that. (the next version of the I-D will be revised as you had suggested off-list) That said (and aside of the project of pursuing this work), I do think that RA-Guard skips important considerations that should be taken into account to implement the "RA-Guard concept" in a real device -- which IMHO are core to the mechanism, rather than just a security consideration. > You can keep rambling the kettle here, Not sure what this expression means (English as second language here) -- anyway I was just asking for feedback. > but keep the above in mind if you desire to proceed with this work. As noted, I'll do. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com web: http://www.si6networks.com | Twitter: @SI6Networks From Jasper.Jans at espritxb.nl Mon Sep 19 11:38:02 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Mon, 19 Sep 2011 11:38:02 +0200 Subject: [ipv6-wg] The DFZ and supernetting Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD2010466149C18@EXCH01.campus.local> Hi, We have had a fair amount of discussions lately on and off this list about the explosion of routes in the DFZ as a result of people wanting PI space and the likes. Others are ofcourse if there is no NAT66 how do you handle multihoming of a small site - but that is besides the point here. I have been wondering - since BGP is all about reachability as a goal and not so much optimal routing/best path/etc. is the easy solution for growth in the DFZ not overly simple? The way I see it you will end up with three sets of routes that you will need to carry on your routers: 1) Own customer routes - these can be any prefix length between /48 and /64 2) Other LIRs aggregates in same RIR region - these are /32 and bigger 3) Supernets for other RIR regions - these are /12 or larger So it seems like the explosion of the DFZ can be managed by supernetting certain routes. Having come up with this idea my next was - ok what am I missing here since it seems a simple and easy fix that would work without breaking much if anything. Can anyone enlighten me why we should not want to head in this direction? Met vriendelijke groet, Jasper Jans Team Leader Network Operations Sr. Network Engineer T: 088 - 00 68 152 F: 088 - 00 68 001 M: 06 - 218 26 380 E: jasper.jans at espritxb.nl EspritXB Monitorweg 1, 1322 BJ Almere Postbus 60043, 1320 AA Almere T: 088 00 68 000 KvK: 1717 7850 F: 088 00 68 001 W: http://www.espritxb.nl http://www.linkedin.com/companies/espritxb http://twitter.com/EspritXB EspritXB levert traditionele spraakdiensten en IP-gebaseerde diensten zoals VoIP, internettoegang, VPN, pinnen, alarm en managed hosting aan MKB Nederland. Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From roger at jorgensen.no Mon Sep 19 12:02:17 2011 From: roger at jorgensen.no (Roger =?iso-8859-1?Q?J=F8rgensen?=) Date: Mon, 19 Sep 2011 12:02:17 +0200 (CEST) Subject: [ipv6-wg] The DFZ and supernetting In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD2010466149C18@EXCH01.campus.local> References: <55557D0EBE9495428BFE94EF8BC5EBD2010466149C18@EXCH01.campus.local> Message-ID: <7594.91.186.65.47.1316426537.squirrel@mail.e-konsult.no> On man, september 19, 2011 11:38, Jasper Jans wrote: > I have been wondering - since BGP is all about reachability as a goal and > not > so much optimal routing/best path/etc. is the easy solution for growth in > the > DFZ not overly simple? The way I see it you will end up with three sets of > routes > that you will need to carry on your routers: > > 1) Own customer routes - these can be any prefix length between /48 and > /64 > 2) Other LIRs aggregates in same RIR region - these are /32 and bigger > 3) Supernets for other RIR regions - these are /12 or larger ... geo adressing? :-) anyway, about #3, how should be it implemented in practice? Who should carry others route in DFZ between regions, and who should distribute it to others? Should RIPE/ARIN/APNIC etc "pay" someone to make region<>region communication possible? and yeah, the idea is sound and I agree but can't really see an easy way to implement it today... -- --- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger at jorgensen.no | - The Future is IPv6 ------------------------------------------------------- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? From Jasper.Jans at espritxb.nl Mon Sep 19 12:40:08 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Mon, 19 Sep 2011 12:40:08 +0200 Subject: [ipv6-wg] The DFZ and supernetting In-Reply-To: <7594.91.186.65.47.1316426537.squirrel@mail.e-konsult.no> References: <55557D0EBE9495428BFE94EF8BC5EBD2010466149C18@EXCH01.campus.local> <7594.91.186.65.47.1316426537.squirrel@mail.e-konsult.no> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD2010466149C7F@EXCH01.campus.local> > > 1) Own customer routes - these can be any prefix length between /48 and > > /64 > > 2) Other LIRs aggregates in same RIR region - these are /32 and bigger > > 3) Supernets for other RIR regions - these are /12 or larger > > ... geo adressing? :-) In a way yea. We have known reservations per RIR region. > anyway, about #3, how should be it implemented in practice? Who should > carry others route in DFZ between regions, and who should distribute it to > others? Should RIPE/ARIN/APNIC etc "pay" someone to make region<>region > communication possible? For the local LIRs I believe they already pay for this - they pay someone for IP transit. So this model seems to work for smaller LIRs - exactly the group of which many have stated they do not have the funding to continiously upgrade their equipment - especially not at the expense of someone else wanting PI space. Apart from picking one transit party over another unless I'm mistaken LIRs already default out to a bigger party these days already. The big boys - the parties that sell IP transit and hence connect in multiple regions - they would not to carry several more routes. I wonder if carrying /12s per region there would be sufficient - probably not. But on the other hand these are usually the parties that already have the bigger routers anyways. > and yeah, the idea is sound and I agree but can't really see an easy way > to implement it today... It is probably far from ideal - just came to me as a means to fix or at least bypass a hurdle for at least the LIRs that can otherwise not keep up with a growing routing table. Jasper Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From millnert at gmail.com Mon Sep 19 12:41:12 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 19 Sep 2011 12:41:12 +0200 Subject: [ipv6-wg] The DFZ and supernetting In-Reply-To: <7594.91.186.65.47.1316426537.squirrel@mail.e-konsult.no> References: <55557D0EBE9495428BFE94EF8BC5EBD2010466149C18@EXCH01.campus.local> <7594.91.186.65.47.1316426537.squirrel@mail.e-konsult.no> Message-ID: <1316428873.24882.84.camel@davinci.millnert.se> On Mon, 2011-09-19 at 12:02 +0200, Roger J?rgensen wrote: > On man, september 19, 2011 11:38, Jasper Jans wrote: > > > I have been wondering - since BGP is all about reachability as a goal and > > not > > so much optimal routing/best path/etc. is the easy solution for growth in > > the > > DFZ not overly simple? The way I see it you will end up with three sets of > > routes > > that you will need to carry on your routers: > > > > 1) Own customer routes - these can be any prefix length between /48 and > > /64 > > 2) Other LIRs aggregates in same RIR region - these are /32 and bigger > > 3) Supernets for other RIR regions - these are /12 or larger > > ... geo adressing? :-) > > > anyway, about #3, how should be it implemented in practice? Good question. > Who should carry others route in DFZ between regions, and who should > distribute it to others? Anyone who so pleases. > Should RIPE/ARIN/APNIC etc "pay" someone to make region<>region > communication possible? Oh dear TCAMs, please no. > and yeah, the idea is sound and I agree but can't really see an easy way > to implement it today... It sounds suspiciously like ITU for me (ie, bad). It imposes previously non-existent architectural limits and constraints on Internet routing (given there is some form of routing police, of course :-)): How would you multi-home across region boundaries? What will happen with other inter-region connectivity? All AS:es who peer over a region-boundary, they will have to stop? (Who can enforce that?) Or will they have to get space from each regions RIR and do prefix translation in their routers? (This will amplify space usage by number of regions, roughly, for operators with presence in more than one region.) Jasper, how did you conclude that RIR region boundaries is a good place to draw the line in the sand by the way? Why, for example, didn't you suggest nation state borders? (Ie, Denmark could have 0045::, Sweden 0046:: and so on) Cheers, Martin From Jasper.Jans at espritxb.nl Mon Sep 19 12:52:21 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Mon, 19 Sep 2011 12:52:21 +0200 Subject: [ipv6-wg] The DFZ and supernetting In-Reply-To: <1316428873.24882.84.camel@davinci.millnert.se> References: <55557D0EBE9495428BFE94EF8BC5EBD2010466149C18@EXCH01.campus.local> <7594.91.186.65.47.1316426537.squirrel@mail.e-konsult.no> <1316428873.24882.84.camel@davinci.millnert.se> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD2010466149C8E@EXCH01.campus.local> > It sounds suspiciously like ITU for me (ie, bad). It imposes previously > non-existent architectural limits and constraints on Internet routing > (given there is some form of routing police, of course :-)): How would > you multi-home across region boundaries? Good point. Only way is ending up with a kludge I guess where for those parties that connect over multiple summarization boundries you do not only carry a summary but also the more specific. Hence you loose effect towards less routes in the table for these parties. > What will happen with other inter-region connectivity? All AS:es who > peer over a region-boundary, they will have to stop? (Who can enforce > that?) > Or will they have to get space from each regions RIR and do prefix > translation in their routers? (This will amplify space usage by number > of regions, roughly, for operators with presence in more than one > region.) That can hardly be a correct way to go down. Sounds like this is for sure one of those items coming in the way of simple aggregation. > Jasper, how did you conclude that RIR region boundaries is a good place > to draw the line in the sand by the way? > Why, for example, didn't you suggest nation state borders? (Ie, > Denmark could have 0045::, Sweden 0046:: and so on) Just picked a boundry - I guess there are multiple boundries where aggregation can take place. For the moment I kinda stuck by the delegations known to me already (RIR/LIR/etc). Depending on how RIRs assign prefixes today you could implement summaries in between the RIR and LIR level. But in light of your point made above - it does seem to me that the more summaries are made on a smaller scale the more exceptions are required. In a way I also felt that it aligns well with what we for instance do - we do IP transit and peering. All peerings are mainly with parties inside Europe. Transit carries all the other traffic which is mainly US/Asia/etc. Jasper Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From maildanrl at googlemail.com Mon Sep 19 14:19:03 2011 From: maildanrl at googlemail.com (Dan Luedtke) Date: Mon, 19 Sep 2011 14:19:03 +0200 Subject: [ipv6-wg] The DFZ and supernetting In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD2010466149C8E@EXCH01.campus.local> References: <55557D0EBE9495428BFE94EF8BC5EBD2010466149C18@EXCH01.campus.local> <7594.91.186.65.47.1316426537.squirrel@mail.e-konsult.no> <1316428873.24882.84.camel@davinci.millnert.se> <55557D0EBE9495428BFE94EF8BC5EBD2010466149C8E@EXCH01.campus.local> Message-ID: 2011/9/19 Jasper Jans : >> It sounds suspiciously like ITU for me (ie, bad). ?It imposes previously >> non-existent architectural limits and constraints on Internet routing That's exactly what I thought. > Why, for example, didn't you suggest nation state borders? If, and only if, anyone really would suggest practically borders, then please no nation state borders. Peering-Regions could be an idea, e.g. AMSIX-region, DECIX-region and at all places where LIRs use to peer. How do LIRs handle the issue at the moment? I guess I would just add a default route to my routing table for one (or more) transit providers. Or buy a better(tm) router if I could afford it. Sorry for being barefaced, but although I appreciate the idea, I just don't think it is doable yet. One cannot aggegrate routes when it is not reflected on the corresponding infrastructure, can one? regards, danrl -- danrl / Dan Luedtke http://www.danrl.de From luigi at net.t-labs.tu-berlin.de Mon Sep 19 14:33:12 2011 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Mon, 19 Sep 2011 14:33:12 +0200 Subject: [ipv6-wg] The DFZ and supernetting In-Reply-To: References: <55557D0EBE9495428BFE94EF8BC5EBD2010466149C18@EXCH01.campus.local> <7594.91.186.65.47.1316426537.squirrel@mail.e-konsult.no> <1316428873.24882.84.camel@davinci.millnert.se> <55557D0EBE9495428BFE94EF8BC5EBD2010466149C8E@EXCH01.campus.local> Message-ID: <90EDCD82-9173-4FE4-87B2-74737475B402@net.t-labs.tu-berlin.de> Hi The same problem (http://tools.ietf.org/html/rfc4984) has been discussed in the Routing Research Group for a couple years. Their discussion has been summarized in: http://tools.ietf.org/html/rfc6115 AFAIR there is a section talking about aggregating prefixes. Luigi On Sep 19, 2011, at 14:19 , Dan Luedtke wrote: > 2011/9/19 Jasper Jans : >>> It sounds suspiciously like ITU for me (ie, bad). It imposes previously >>> non-existent architectural limits and constraints on Internet routing > That's exactly what I thought. > >> Why, for example, didn't you suggest nation state borders? > If, and only if, anyone really would suggest practically borders, then > please no nation state borders. > Peering-Regions could be an idea, e.g. AMSIX-region, DECIX-region and > at all places where LIRs use to peer. > > How do LIRs handle the issue at the moment? I guess I would just add a > default route to my routing table for one (or more) transit providers. > Or buy a better(tm) router if I could afford it. Sorry for being > barefaced, but although I appreciate the idea, I just don't think it > is doable yet. > > One cannot aggegrate routes when it is not reflected on the > corresponding infrastructure, can one? > > regards, > danrl > > -- > danrl / Dan Luedtke > http://www.danrl.de > From cris.pascual.gonzalez at gmail.com Tue Sep 20 17:22:02 2011 From: cris.pascual.gonzalez at gmail.com (Cristina Pascual) Date: Tue, 20 Sep 2011 17:22:02 +0200 Subject: [ipv6-wg] 2nd CfP: MMEDIA 2012 || April 29 - May 4, 2012 - Chamonix / Mont Blanc, France Message-ID: <201109201522.p8KFM191023893@smtp.upv.es> INVITATION: ================= Please, consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results to MMEDIA 2012. The submission deadline is set to December 5, 2011. In addition, authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== MMEDIA 2012 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS MMEDIA 2012: The Fourth International Conferences on Advances in Multimedia April 29 - May 4, 2012 - Chamonix / Mont Blanc, France General page: http://www.iaria.org/conferences2012/MMEDIA12.html Call for Papers: http://www.iaria.org/conferences2012/CfPMMEDIA12.html - regular papers - short papers (work in progress) - posters - ideas Submission page: hhttp://www.iaria.org/conferences2012/SubmitMMEDIA12.html Submission deadline: December 5, 2011 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and conform with the Editorial rules: http://www.iaria.org/editorialrules.html MMEDIA 2012 Topics (topics and submission details: see CfP on the site) Fundamentals in multimedia Multimedia systems, architecture, and applications; New multimedia platforms; Multimedia architectural specification languages; Theoretical aspects and algorithms for multimedia; Multimedia content delivery networks; Network support for multimedia data; Multimedia data storage; Multimedia meta-modeling techniques and operating systems; Multimedia signal coding and processing (audio, video, image); Multimedia applications (telepresence, triple-play, quadruple-play, ?); Multimedia tools (authoring, analyzing, editing, browsing, ?); Computational multimedia intelligence (fuzzy logic, neural networks, genetic algorithms, ?); Intelligent agents for multimedia content creation, distribution, and analysis; Multimedia networking; Wired and wireless multimedia systems; Distributed multimedia systems; Multisensor data integration and fusion; Multimedia and P2P; Multimedia standards Multimedia content and modeling Interfaces for multimedia creation; Multimedia streaming and services; Image modeling and editing; Audio modeling and transformation; Video modeling and transformation; Image recognition; Multimedia databases; Multimedia coding and encryption; Multimedia modeling for learning content; Multimedia description languages; Image clustering; Media fusion for communication and presentation Self-organizing multimedia architectures Self-organization in multimedia systems; Self-organization in multimedia communities; Self-organized multimedia networks; Multimedia content distribution and consumption; Adaptive multimedia interfaces; Multimedia retrieval Multimedia content-based retrieval and analysis Multimodal data analysis; Multimedia databases; Semi-automatic and automatic methods for multimedia annotation; Image/video/audio databases; Content-based image retrieval; Semantics-based search and integration of multimedia and digital content; Multimedia data modeling, indexing, and mining; Statistical modeling of multimedia data; Multimedia extraction and annotation; Content search/browsing/retrieval; Internet imaging and multimedia; Multimodal content analysis; Multimedia abstraction and summarization; Semantic analysis of multimedia data; Media assimilation and fusion Perception and cognition for multimedia users Quality of experience; Relevance feedback; Human-computer interaction; Multimodal interaction; Multimodal user interfaces; Mobile user-centered interfaces; Peer-to-peer multimedia systems and streaming; Pervasive and interactive multimedia systems (digital TV, mobile systems, gaming,?); Multimedia in personal, sensor and ad-hoc networks; Visualization and virtual reality; Intelligent browsing and visualization; Perception and cognition; Perception and modeling of the environment; Multimedia collaboration; Social networking Multimedia ontology Multimedia semantics; Emergent semantics; Media ontology learning; Ontology for media web mining; Multimedia ontologies; Multimedia information management; Approaches using metadata standards; Conceptual clustering; Modeling and recognition of visual objects and actions Mobile and ubiquitous multimedia Architectures, protocols, and algorithms for multimedia mobility; Middleware and distributed computing support for mobile and ubiquitous multimedia; Mobile and ubiquitous multimedia in intelligent transportation systems; Enabling platforms for mobile multimedia; Roaming and limited bandwidth; Intermittent connectivity; Streaming mobile multimedia; Mobile multimedia software architectures; Mobile multimedia applications and services; Communication and cooperation via mobile multimedia; Business models for mobile multimedia; Provisioning of mobile multimedia services; Context-aware mobile and ubiquitous multimedia; Mobile computer graphics, games and entertainment; Mobile and ubiquitous multimedia in ad hoc networks; Personalization, privacy and security in mobile multimedia; Social and regulatory aspects of mobile multimedia; Multimedia in the Extended Home; Ubiquitous/Seamless content sharing Multimedia services Reliability, availability, serviceability of multimedia services; Multimedia content distribution services; Real-time multimedia services; Audio-visual multimedia services; Multimedia signal processing and communications; Media representation and algorithms; Audio, image, video processing, coding and compression; Multimedia database, content delivery and transport; Multimedia service protocols; Mobility of multimedia services; Internet telephony and hypermedia technologies and systems; Media enabled eCommerce service; Case studies, field trials and evaluation of new multimedia services Multimedia applications Real-time interactive multimedia applications Adaptive and context-aware multimedia applications; Ambiance multimedia applications; Media applications on mobile devices; Multi-modal interaction; Virtual environments; Personalization; Collaboration, contextual metadata, collaborative tagging; Web applications; Multimedia authoring; Multimedia-enabled new applications (eLearning, entertainment,?..); Cooperative networks and applications; Mobile multimedia applications & services; Semantic metadata for mobile applications; Semantics enabled multimedia applications; Semantics enabled networks and middleware for multimedia applications; Wireless ad-hoc and sensor networks/RFID applications Industrial use-cases and applications Multimedia security and content protection Multimedia security (watermark, encryption,? ); Mobile multimedia systems and services; Security, privacy, and cryptographic protocols; Network security issues and protocols; Key management and authentication; Authentication and access control; Intrusion detection and prevention; Content protection and digital rights management; Trusted computing; Information hiding; Protection of user-generated content Multimedia control and management Wireless and mobile multimedia network management; Multimedia measurement, control, and management; Content management and delivery; IP multimedia system operations and management; Managing the quality of experience and quality of service; Measuring the quality of performance in multimedia systems; Mobile multimedia network traffic engineering and optimization; Monitoring and managing mobile multimedia; Resource reservation for multimedia services; Multicast and broadcast multimedia service management; Management of service oriented architectures; Pricing, accounting and billing for multimedia services Committee: http://www.iaria.org/conferences2012/ComMMEDIA12.html ==================== From david.kessens at nsn.com Thu Sep 29 00:51:42 2011 From: david.kessens at nsn.com (David Kessens) Date: Wed, 28 Sep 2011 15:51:42 -0700 Subject: [ipv6-wg] Second Call for IPv6 WG agenda items Message-ID: <20110928225142.GA6492@nsn.com> Hi, The RIPE meeting is now only a month away and we have not received a lot of proposals for our session yet. We would appreciate if you could approach us with proposals as soon as possible as we would like to publish a draft agenda well before the meeting. All topics that can contribute to a better understanding of the issues involved with the deployment of IPv6 are welcome: we can accommodate a single question that needs discussion to more complicated topics that need slides. Finally, other proposals for the plenary program can be submitted to the program committee via http://ripe63.ripe.net/programme/submit-a-topic/. Thanks, David, Marco and Shane --- Date: Mon, 29 Aug 2011 15:22:23 +0200 From: Marco Hogewoning To: ipv6-wg at ripe.net Subject: [ipv6-wg] RIPE 63 Registration and call for IPv6 WG agenda items Dear Colleagues, Registration for RIPE 63 is now open, this meeting will take place from October 31 until November 4 in Vienna, Austria. More information about this meeting, the venue and the online registration form can be found at http://ripe63.ripe.net/. If you wish to add an item to the IPv6 Working Group agenda, either something to discuss or something you want to present, please contact us via ipv6-wg-chairs [at] ripe [dot] net. Alternatively proposals for content can be submitted to the programme committee via http://ripe63.ripe.net/programme/submit-a-topic/. Deadline for these proposals is September 18th. We hope to see you all in Vienna, The chairs of the IPv6 Working Group, Marco, David and Shane ----- End forwarded message ----- From ip at ioshints.info Thu Sep 29 10:32:13 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Thu, 29 Sep 2011 10:32:13 +0200 Subject: [ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet In-Reply-To: <20110928225142.GA6492@nsn.com> References: <20110928225142.GA6492@nsn.com> Message-ID: <00a701cc7e82$4b3f4e30$e1bdea90$@info> Hi, Trying to figure out how to do IPv6 address allocation for consumer customers connecting their end-hosts (Windows/OSX/Linux) directly to a Carrier Ethernet network/VLAN (obviously through some sort of fiber-to-Ethernet converter/bridge). The particular problem bothering me is user-to-address mapping traceability that you might need for regulatory/law enforcement reasons. I see the following options: #1 - use DHCPv6 instead of SLAAC ================================ Requires support for DHCPv6 Option37/38 and L3 switches all the way to the end-user (unless your favorite vendor supports L2 DHCPv6 extensions) and allows any third-party to track the user based on pretty static IPv6 address. Also requires DHCPv6 snooping/IPv6 source guard to prevent overly-easy spoofing. #2 - use SLAAC and don't care ============================= Consumer hosts will get random IPv6 addresses out of your Carrier Ethernet /64 prefix. Can you afford the "don't care" part of it? #3 - use CPE devices that only allow DHCPv6 IA_PD ================================================= This might be the cleanest approach (you map the customer into an IPv6 prefix), but it requires strict control of the CPE devices by the SP (think cable modems). #4 - use PPPoE over Carrier Ethernet ==================================== Been there, seen that. Not sure we can afford the performance/licensing hits. However, it does solve the authentication problems (PAP/CHAP), address tracking (RADIUS accounting records), randomized addresses (use local pool on the PE-router). Anything I've missed or is it really so bleak? Thanks Ivan From sander at steffann.nl Thu Sep 29 11:56:28 2011 From: sander at steffann.nl (Sander Steffann) Date: Thu, 29 Sep 2011 11:56:28 +0200 Subject: [ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet In-Reply-To: <00a701cc7e82$4b3f4e30$e1bdea90$@info> References: <20110928225142.GA6492@nsn.com> <00a701cc7e82$4b3f4e30$e1bdea90$@info> Message-ID: <8D9B39DE-3E07-464B-A35E-9BA856B90F3B@steffann.nl> Hi, > #2 - use SLAAC and don't care > ============================= > Consumer hosts will get random IPv6 addresses out of your Carrier Ethernet /64 prefix. Can you afford the "don't care" part of it? There is a sub-option here: use SLAAC and track/log which address is used by which customer (based on port and/or MAC address). It is easiest for the end user, it will provide data for the LEA, but it does require monitoring and logging of ND traffic. I know that some Dutch universities are doing it like this. Met vriendelijke groet, Sander Steffann -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From jan at pragma.si Thu Sep 29 12:12:12 2011 From: jan at pragma.si (Jan Zorz) Date: Thu, 29 Sep 2011 12:12:12 +0200 Subject: [ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet In-Reply-To: <00a701cc7e82$4b3f4e30$e1bdea90$@info> References: <20110928225142.GA6492@nsn.com> <00a701cc7e82$4b3f4e30$e1bdea90$@info> Message-ID: <4E84447C.7000602@pragma.si> On 9/29/11 10:32 AM, Ivan Pepelnjak wrote: > #4 - use PPPoE over Carrier Ethernet > ==================================== > Been there, seen that. Not sure we can afford the performance/licensing hits. > > However, it does solve the authentication problems (PAP/CHAP), address tracking (RADIUS accounting records), randomized addresses (use local pool on the PE-router). > > Anything I've missed or is it really so bleak? MIP6 or DSMIP6-TLS is also an option, but we need more mature product for that in the near future. /jan From Tero.Toikkanen at nebula.fi Thu Sep 29 13:55:00 2011 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Thu, 29 Sep 2011 11:55:00 +0000 Subject: [ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet In-Reply-To: <00a701cc7e82$4b3f4e30$e1bdea90$@info> References: <20110928225142.GA6492@nsn.com> <00a701cc7e82$4b3f4e30$e1bdea90$@info> Message-ID: > #2 - use SLAAC and don't care > ============================= > Consumer hosts will get random IPv6 addresses out of your Carrier Ethernet > /64 prefix. Can you afford the "don't care" part of it? We provide a static /64 with SLAAC per connection, but allow static addresses within that /64 as well. Connections are provisioned as individual router subinterfaces, so user-to-address mapping happens on subnet level and URPF prevents spoofing. This naturally works only as long as you have a single customer/connection per VLAN, not so much with group-VLANs (which are shared by several connections). With SLAAC you can dig the MAC address from the IPv6-address, if necessary (MAC-spoofing can be a problem, but that's the case with DHCP and IPv4-world as well. ND-attacks are an issue as well.) The shortcomings with this approach include: - doesn't work with group-VLANs - the end-user has to configure DNS-servers manually ____________________________________ Tero Toikkanen Network Engineer Nebula Oy From ip at ioshints.info Thu Sep 29 14:04:00 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Thu, 29 Sep 2011 14:04:00 +0200 Subject: [ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet In-Reply-To: References: <20110928225142.GA6492@nsn.com> <00a701cc7e82$4b3f4e30$e1bdea90$@info> Message-ID: <002301cc7e9f$e146dfc0$a3d49f40$@info> You can't extract MAC from SLAACed IPv6 due to privacy extensions (RFC 4941). I like one-VLAN-per customer idea, but it doesn't always scale (in some environments you'd run out of VLANs). Thanks! Ivan > -----Original Message----- > From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf > Of Tero Toikkanen > Sent: Thursday, September 29, 2011 1:55 PM > To: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] End-host IPv6 address allocation on Carrier > Ethernet > > > #2 - use SLAAC and don't care > > ============================= > > Consumer hosts will get random IPv6 addresses out of your Carrier > Ethernet > > /64 prefix. Can you afford the "don't care" part of it? > > We provide a static /64 with SLAAC per connection, but allow static > addresses within that /64 as well. Connections are provisioned as > individual router subinterfaces, so user-to-address mapping happens on > subnet level and URPF prevents spoofing. This naturally works only as long > as you have a single customer/connection per VLAN, not so much with group- > VLANs (which are shared by several connections). With SLAAC you can dig > the MAC address from the IPv6-address, if necessary (MAC-spoofing can be a > problem, but that's the case with DHCP and IPv4-world as well. ND-attacks > are an issue as well.) > > The shortcomings with this approach include: > - doesn't work with group-VLANs > - the end-user has to configure DNS-servers manually > > ____________________________________ > Tero Toikkanen > Network Engineer > Nebula Oy From Tero.Toikkanen at nebula.fi Thu Sep 29 14:36:23 2011 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Thu, 29 Sep 2011 12:36:23 +0000 Subject: [ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet In-Reply-To: <002301cc7e9f$e146dfc0$a3d49f40$@info> References: <20110928225142.GA6492@nsn.com> <00a701cc7e82$4b3f4e30$e1bdea90$@info> <002301cc7e9f$e146dfc0$a3d49f40$@info> Message-ID: > You can't extract MAC from SLAACed IPv6 due to privacy extensions (RFC > 4941). Ah, I had already forgotten about that. > I like one-VLAN-per customer idea, but it doesn't always scale (in some > environments you'd run out of VLANs). Q-in-Q helps with the scaling, but admittedly only up to a certain point. As mentioned, we also have to come up with an alternative solution for the group-VLANs. So far DHCPv6 seems like the way to go in that case, but vendor support is still lacking. DHCPv6 IA_PD would be nice, but in 98% of the time we don't have control over the CPE. As Ivan mentioned, DHCPv6 Option37/38 would enable the same for IPv6, but the support just isn't there yet. Also, it's one thing to get vendor support and another thing to get bitstream operators to support it as well. ____________________________________ Tero Toikkanen Network Engineer Nebula Oy From jan at go6.si Thu Sep 29 14:46:15 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 29 Sep 2011 14:46:15 +0200 Subject: [ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet In-Reply-To: <002301cc7e9f$e146dfc0$a3d49f40$@info> References: <20110928225142.GA6492@nsn.com> <00a701cc7e82$4b3f4e30$e1bdea90$@info> <002301cc7e9f$e146dfc0$a3d49f40$@info> Message-ID: <4E846897.2060807@go6.si> On 9/29/11 2:04 PM, Ivan Pepelnjak wrote: > You can't extract MAC from SLAACed IPv6 due to privacy extensions (RFC 4941). Listen on multicast and log. /jan From rk at vzsze.de Thu Sep 29 15:04:31 2011 From: rk at vzsze.de (Rolf Kutz) Date: Thu, 29 Sep 2011 15:04:31 +0200 Subject: [ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet In-Reply-To: <00a701cc7e82$4b3f4e30$e1bdea90$@info> References: <20110928225142.GA6492@nsn.com> <00a701cc7e82$4b3f4e30$e1bdea90$@info> Message-ID: <20110929130431.GD14207@vzsze.de> Hi, I'm Rolf from German Working Group on Data Retention (Arbeitskreis Vorratsdatenspeicherung). I'm on this list because we like to learn about the privacy impacts of the growing IPv6 deployment. On 29/09/11 10:32 +0200, Ivan Pepelnjak wrote: >Trying to figure out how to do IPv6 address allocation for consumer customers connecting their end-hosts (Windows/OSX/Linux) directly to a Carrier Ethernet network/VLAN (obviously through some sort of fiber-to-Ethernet converter/bridge). > >The particular problem bothering me is user-to-address mapping traceability that you might need for regulatory/law enforcement reasons. If I understand correctly there can not be a user-to-address mapping on IP level, just a nic-to-address mapping. In Germany it's not mandatory to log this kind of information proactively. Does law enforcement provide a list of mac address of the device? to be monitored? regards Rolf -- Sous les pav?s, la plage