Re: [ietf-privacy] New Webiquette RFC
This submission raises an interesting question for the IETF: how to treat anonymous (or pseudonymous) submissions? On one hand, there are lots of classic reasons for hiding behind a pseudonym when participating in public discussions. On the other hand, the IETF has to be protected against intellectual property issues and against sabotage by external groups. Before submissions are accepted for publication, their authors have to disclose whether they, or their employer, own intellectual property rights on the technologies described in the draft. Failure to disclose would influence the prosecution of intellectual property disputes that might arise when third parties implement the technology. This provides some degree of protection to implementers. But when the submission cannot be traced to a specific company, these protections disappear, and we might have a problem. So this is one source of tension between standards and anonymity. The other source of tension is the risk of sabotage. Various groups have tried to sabotage the standard process in the past, for example to delay the deployment of encryption, or to introduce exploitable bugs in security standards -- some of these tactics were exposed in the Snowden revelations. Anonymous participation could allow these groups to perform such sabotage in untraceable ways, which is obviously not desirable. I think this issue of anonymous participation is worth discussing. -- Christian Huitema On 4/17/2022 11:35 AM, kate_9023+...@systemli.org wrote: Dear all, I'm quite new at creating RFCs. I have recently submitted a draft for a new webiquette and I am still searching a group which will take care of it. It would fit into privacy as this new webiquette is dealing with new internet technology such as deepfakes, sharing photos of 3rd parties and so on and also deleting old information on a regular basis good behavior. It's also quite short with only 9 pages and also covers cancel culture and mobbing. I think a document like this is needed and important. Anyone here who'd like to take care or helping me making an RFC out of it? Or guide me in the right direction? The draft can be found here: https://www.ietf.org/archive/id/draft-rfcxml-general-the-new-webiquette-00.txt Best Regards, Kate ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt
(Moving this conversation to DNS-SD mailing list) On Thursday, June 23, 2016 2:53 AM, S Moonesamy wrote: > > Hi Tim, > At 05:18 22-06-2016, Tim Chown wrote: > >We're encouraging discussion of privacy considerations in the WG. As a > >result, we now have a draft (see below), including an initial proposal > >for a solution, for which we'd welcome wider review. The draft also > >addresses mDNS/DNS-SD privacy within single subnet scenarios. > > One of the privacy issue identified in the draft (Section 2.4) is device > fingerprinting. In Section 3.1, it is proposed to solve the privacy issues > described in Section 2.1 by obfuscating instance names. If I had to pick one > privacy threat for that I would choose "correlation". Obfuscating service names > would not address that. Section 3 describes an initial design that was then abandoned. I guess that in the next revision we could just remove that section entirely. On the other hand, the proposal was indeed to use different obfuscated names at different locations. > If I understood the draft correctly, the solution "to prevent tracking over time > and location, different string values would be used at different locations, or at > different times". QR-codes are used to generate a shared secret and establish > trust between two or more "friends". The private discovery service relies on pre-existing pairings. The pairing solutions are only drafted in very vague terms in the draft. I really wonder whether we should go define a complete pairing protocol. Is that in-charter for DNS-SD? What about competing with existing solutions over Bluetooth, Wi-Fi, and certainly many more? -- Christian Huitema ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Is there an official working definition for Privacy Online?
On Friday, April 17, 2015, at 9:14 AM, Dave Crocker wrote ... This translates into privacy relates to controlling disclosure of information about a person or organization. Then add the scope-of-control portion. There is indeed some fuzziness in the definition of privacy. I like the analysis in this Pew Research Center study on Public Perceptions of Privacy and Security in the Post-Snowden Era: http://www.pewinternet.org/2014/11/12/public-privacy-perceptions/. I think they do a good job relating threats to privacy and threats to personal security. To quote: Beyond the frequency of individual words, when responses are grouped into themes, the largest block of answers ties to concepts of security, safety, and protection. For many others, notions of secrecy and keeping things 'hidden' are top of mind when thinking about privacy. -- Christian Huitema ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
[ietf-privacy] PPM Review of RFC 1108
This RFC defines an IP header option for security options. The options enable hosts to mark their traffic as belonging to a particular security level. Presumably, secure routers will ensure that traffic marked with a specific security option is contained within a network that meets the corresponding security requirements. The RFC was written in 1988, before we started writing security considerations in RFC. A security consideration section would probably have listed the two major issues with the option, use by unauthorized hosts and use in unsecure networks. If a network allows for traffic from both secure and unsecure sources, unsecure sources can easily insert spoof IP addresses and insert options in the IP header. This could be used for sending attack packets to secure system, despite attempts at compartmenting the network. Ping of death and variants come to mind. A mobile host that is allowed to send secure traffic may inadvertently visit an insecure network. In that case, using the option provides for easy identification of the host as a potential target. Mobile hosts were not common in 1988, and this threat was not envisaged in the RFC. This was then. By now, IP options are very rarely used. The RFC should probably be reclassified as historic. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] PPM Review of RFC 1108
That was my attempt at using the random lottery. I like using the issue page better for input. Also, I prefer reading the html version of the RFC from the IETF tools page. Maybe the lottery should just give you a suggestion of an RFC number… From: ietf-privacy [mailto:ietf-privacy-boun...@ietf.org] On Behalf Of Christian Huitema Sent: Wednesday, May 21, 2014 9:10 PM To: ietf-privacy@ietf.org Subject: [ietf-privacy] PPM Review of RFC 1108 This RFC defines an IP header option for security options. The options enable hosts to mark their traffic as belonging to a particular security level. Presumably, secure routers will ensure that traffic marked with a specific security option is contained within a network that meets the corresponding security requirements. The RFC was written in 1988, before we started writing security considerations in RFC. A security consideration section would probably have listed the two major issues with the option, use by unauthorized hosts and use in unsecure networks. If a network allows for traffic from both secure and unsecure sources, unsecure sources can easily insert spoof IP addresses and insert options in the IP header. This could be used for sending attack packets to secure system, despite attempts at compartmenting the network. Ping of death and variants come to mind. A mobile host that is allowed to send secure traffic may inadvertently visit an insecure network. In that case, using the option provides for easy identification of the host as a potential target. Mobile hosts were not common in 1988, and this threat was not envisaged in the RFC. This was then. By now, IP options are very rarely used. The RFC should probably be reclassified as historic. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] Wiki for managing PPM reviews of existing RFCs
If you were at the Monday lunch and announced an intention to working on a particular set of RFCs, now there's a home for your reviews. If you couldn't commit to doing reviews but want to do some, here is your chance! (If you don't have a login on the wiki, it's easy to register.) In both cases, please add a ticket when you _start_ your review -- don't wait until you finish, people will want to know all about it from the start. I added a couple of tickets for the various DHCP RFC that I reviewed when writing the DHCP draft. What is the process for picking new RFC to review? Just pick one at random and write a provisional ticket in https://trac.tools.ietf.org/group/ppm-legacy-review/wiki ? -- Christian Huitema ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
RE: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
Yes. $$$. Nobody makes much/any money off email because it is so de-centralized. People who build wonderful new applications build them in a centralized way so that they can control them. And they want to control them so that they can monetize them. That is even true of the large email providers who are happy to provide free email in return for being able leverage their other products and/or sell the users and user base to advertisers. It is very true that innovation can only be sustained with a revenue stream. But we could argue that several services have now become pretty much standardized, with very little additional innovation going on. Those services are prime candidates for an open and distributed implementation. I mean, could a WG design a service that provides a stream of personal updates and a store of pictures and is only accessible to my friends? And could providers make some business by selling personal servers, or maybe personal virtual servers? Maybe I am a dreamer, but hey, nothing ever happens if you don't dream of it! -- Christian Huitema
RE: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, September 19, 2013 9:55 PM To: IETF discussion list Subject: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt] I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. Brian Original Message Subject: I-D Action: draft-carpenter-prismatic-reflections-00.txt Date: Thu, 19 Sep 2013 21:47:18 -0700 From: internet-dra...@ietf.org Reply-To: internet-dra...@ietf.org To: i-d-annou...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Prismatic Reflections Author(s) : Brian Carpenter Filename: draft-carpenter-prismatic-reflections-00.txt Pages : 9 Date: 2013-09-19 Abstract: Recent public disclosure of allegedly pervasive surveillance of Internet traffic has led to calls for action by the IETF. This draft exists solely to collect together a number of possible actions that were mentioned in a vigorous discussion on the IETF mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-prismatic-reflections There's also a htmlized version available at: http://tools.ietf.org/html/draft-carpenter-prismatic-reflections-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
RE: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. Brian, This is a useful summary, but I would like to see a few additions: 1) Encourage protocol designs that rely on peer-to-peer transmission, rather than intermediate relays, because relays are natural targets for interception services. 2) Encourage distributed services over centralized services. For example, social networking services today are heavily centralized. A distributed architecture would allow distribution of data at multiple location, managed by different commercial companies and covered by different legal authorities. 3) Require security sections of new RFC to include mass surveillance in their threat model and consider mitigations. -- Christian Huitema
RE: Faraday cages...
Why bother with RFID tags, or badges? Simply register with your cell phone. We can then scan your Wi-Fi and Blue-Tooth signals when you approach the mic. -- Christian Huitema 'Simply' What is this simple technology of which you speak? I find that the best we can do with electronic systems is about 99% and that takes a huge amount of effort. I have a whole drawerful of bluetooth headsets and thats where they will stay because none of them works well enough to be useful. I am fairly sure Christian was being ironic. :-) I was. On the other hand, there are systems out there that will, for example, track customers as they move in a shop. They do that by listening to the Bluetooth radios. They definitely do not requests the customers to install an application or pair their devices. An extract form a research paper on the subject (http://www.gim-international.com/issues/articles/id1443-Bluetooth_Tracking.html) asserts that Bluetooth tracking on the basis of MAC addresses does not violate privacy law. In fact, it simply makes use of a general Bluetooth function: scanning for nearby devices. Everyone is free to use this function, for instance when turning on a mobile phone in a public place. So it must be just fine. -- Christian Huitema
RE: Faraday cages...
Unless we adopt the WIDE practice where the tag is re-used from meeting to meeting. It's an elegant solution, and not that different from the reason I own a complete set of Suica, Pasmo, ICOCA, PASPY and London Oyster cards. That is where I was going with that remark, yes. :) Why bother with RFID tags, or badges? Simply register with your cell phone. We can then scan your Wi-Fi and Blue-Tooth signals when you approach the mic. -- Christian Huitema
RE: IETF Diversity Question on Berlin Registration?
All of which is why we should limit our attempts to do numerical analysis for this topic, and worry far more about the basics, including such things as interaction (in)sensitivities, group tone and style, and observable misbehaviors, all of which are likely to produce biasing results. Certainly useful, but it is easy to inject one's own bias into such processes, and to overlook other factors. I may be biased, but I have the impression that the largest source of bias in IESG selection is the need to secure funding for the job, which effectively self-select people working for large companies making networking products. Gender may be the least of the problems there; there are other dimensions of diversity, e.g. academic vs. industry, network equipment versus internet service providers, software versus hardware, etc. Only a fraction of these segments can afford to have someone working full-time on the IESG. Now, having to work full time is a bit much for a volunteer position, and we may want to consider ways to remedy that. -- Christian Huitema
RE: IETF Diversity Question on Berlin Registration?
Except that the IESG members select the wg chairs, which makes your baseline stastistic suspect; it's too easy for all sorts of biasing factors to sway the allocation of wg chair positions. Mike actually mentioned that. Let's assume a simplified curriculum of participant - author/editor - WG chair - IESG, which more or less reflects increasing seniority in the IETF. We may suspect that there is bias that, at each step, privileges some candidates over others. However, the mechanisms are different at each step. Self-selection, selection by WG chair, selection by the nom com. It makes sense to assess the filtering effect of each step independently, and in particular to assess the nomcom by comparing the pool of WG chairs to the selected nominees. -- Christian Huitema
RE: last call comments for draft-ietf-6man-stable-privacy-addresses-06
Sorry I wasn't clear: what is the benefit of specifying the algorithm, when simply popping out another PRF will in just about any instance do the job (unless you are reinitializing the PRF with the same seed)? There seems to be a disconnect here: We want an algorithm that, roughly speaking, whenever you connect to the same network, gives you the same address. But such address should be different for each network you connect to. The question here is: How do you achieve that? You might argue that, clearly, the autoconf prefix needs to be part of the seed (I'd personally not expect developers to figure this one out). This is the kind of attitude that really does not go well with actual developers. You are basically saying that you expect developers to be too dumb to understand what they are doing, and thus you feel compelled to specify an algorithm in its most minute details, even though there are dozens of equally good ways to achieve the same result. The net result of such over-specification is that developers will discard the spec as arrogant, and implement what they fell like implementing. -- Christian Huitema
RE: last call comments for draft-ietf-6man-stable-privacy-addresses-06
After reading the document again, the main issue is that the document specifies a solution to a problem by detailing a specific implementation, but does not explain the design choices behind that solution. As such, we end up with an over constrained specification, which at the same time fails to explain the problems at hand. The specification aims at providing addresses that are stable and different, so that the same host connecting will have different and uncorrelated addresses when connecting to different networks, but will keep the same address when connecting repeatedly to the same network. As Mike St-Johns pointed out, the solution is trivial: create a different random number each time the host connect to a new network; make sure that the same random number is reused if the host reconnect to the same network. The latter property can be achieved either by keeping of log of previously visited networks and the corresponding address, or by using a master random number and combining it with the identification of the visited network. In theory, that's about all what the IETF ought to specify. Instead, the draft goes into great details on how to actually implement the random number generator. Apart from not being necessary, some of these details are wrong. For example, the suggested algorithm includes an interface index, but different operating systems have different ways of enumerating interfaces, and the variations in enumeration could end up violating the stable address property. I would suggest reworking the draft to separate a normative section, effectively a variation of the 3 lines paragraph above, and an informational section, the current specification of the algorithm as an example of a way to achieve this result if the operating system meets certain condition, like stable interface identifiers. I would also explain the inherent issues that have to be solved, e.g., swapping interfaces, or enabling multi-homed hosts. And I would observe that the DAD problem cannot be solved ina reliable way. -- Christian Huitema
RE: last call comments for draft-ietf-6man-stable-privacy-addresses-06
If I'm the guy producing a spec, my goal is to produce a spec that is clear as possible, and only leave open those bits that are necessary to leave open. Well, that might work for internal specs when you are managing a project, but that's probably not the right way to approach standards. A standard, being the rules of the network, shall only constrain what must be constrained for interoperability. All implementations are tradeoffs. Developers will necessarily make them, based on the different resource, priorities, usage scenarios. It is much better to explain to give clear guidelines than to merely mandate an implementation. -- Christian Huitema
RE: IETF Diversity Question on Berlin Registration?
This is a variation of the old boys club. Let's say that there are two candidates. Candidate A has 20 years of IETF experience. Candidate B has 5 years of IETF experience. If the choice is about choosing the best Candidate A will always be selected. There may well be some of that going on, but there is something else as well, tied to very large time commitment required for area directors. At some point, the candidate has to be able to say something like I spoke to my boss and he agrees with the time commitment. We already know that this creates a bias towards large companies whose products are directly affected by IETF standards. But it also creates a bias towards folks who are well connected inside their own company, and can use these connections to get someone to agree to foot their bill. And being well connected is typical of the old boys clubs. Bias reduction would certainly be much easier if the time commitment required from volunteers was not so large. -- Christian Huitema
RE: Sufficient email authentication requirements for IPv6
IPv6 makes publishing IP address reputations impractical. Since IP address reputation has been a primary method for identifying abusive sources with IPv4, imposing ineffective and flaky replacement strategies has an effect of deterring IPv6 use. In practice, the /64 prefix of the IPv6 address has very much the same administrative properties as the /32 value of the IPv4 address. It should be fairly straightforward to update a reputation system to manage the /64 prefixes of IPv6. This seems somewhat more practical than trying to change the behavior of mail agent if their connectivity happens to use IPv6. -- Christian Huitema
RE: Less Corporate Diversity
Melinda is right about the gatekeeping role of the IETF. I have personally experienced that several times. Negotiating that gatekeeping may well be the hardest part of getting a work started. And it mostly has to do with one's capacity to convince the relevant AD of the value of the work. This is probably why the diversity of viewpoints in the steering group is most useful. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Melinda Shore Sent: Friday, March 22, 2013 7:33 PM To: Stephen Farrell Cc: ietf@ietf.org Subject: Re: Less Corporate Diversity On 3/22/13 6:28 PM, Stephen Farrell wrote: FWIW, seems to me you're describing one leg of the elephant each. From my experience I'd say you both actually have an appreciation of the overall elephant but that's not coming out in this kind of thread. Well, maybe, but it seems to me that he's lost track of the discussion. My argument is that the IESG has a gatekeeping function in taking on new work, that's based (aside from resourcing) on a set of values, their view of what's needed in the industry, etc. With a uniform IESG membership you're not going to get a rather uniform view of the overall context for IETF work, you'll lose perspective, and consequently there's value to having members who aren't almost all from big manufacturers. I'm not sure what Martin's point is, to be honest. Melinda
RE: In Memoriam IETF web page -- a modest proposal
Memorials are for the living. The dead typically have ceased to care. I don't know what a simple listing will achieve. The war monuments that Ted mention sort of educate the living by reminding them of the massive sacrifices that wars cause. Just listing a bunch of names will not help all that much. After all, most of these names are already listed in the RFC record. A memorial RFC has more potential. A bit like what the catholic Church does by publishing the life of the saints. The results could be interesting. From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] on behalf of Steve Crocker [st...@shinkuro.com] Sent: Monday, October 22, 2012 1:25 PM To: ietf@ietf.org Subject: Re: In Memoriam IETF web page -- a modest proposal After watching the traffic on this, I'm thinking a memorial page is perhaps not the first place to focus attention. Instead, write a memorial RFC for each person you think made a significant contribution to the IETF. The RFC Editorial process will provide some vetting on quality. Use Informational, Historic(!) or create a new class. The memorial page can then list those who have memorial RFCs written for them. Steve
RE: Last Call: draft-vegoda-cotton-rfc5735bis-02.txt (Special Use IPv4 Addresses) to Best Current Practice
Very useful document, certainly worth publishing. It is one of those documents that needs frequent updates. RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators, makes reference to a predecessor of this document, stating in section 3.1 that The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735]. I assume that implementers will automatically upgrade their code to reference the new version. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randy Bush Sent: Friday, July 13, 2012 4:21 PM To: IETF Disgust; The IESG Subject: Re: Last Call: draft-vegoda-cotton-rfc5735bis-02.txt (Special Use IPv4 Addresses) to Best Current Practice The IESG has received a request from an individual submitter to consider the following document: - 'Special Use IPv4 Addresses' draft-vegoda-cotton-rfc5735bis-02.txt as Best Current Practice read and support randy
RE: IAOC and permissions [Re: Future Handling of Blue Sheets]
Brian, I suggest that your standard dealings with local hosts should include requiring them to perform a local check on whether the standard Note Well takes account of all local legal requirements, including for example consent to publication of images. If it doesn't, the host should provide an augmented Note Well for use during meeting registration. Rather than going this route, we might consider some better balance between privacy and standard-settings. Taking and publishing a person's image is a step above listing their names. Do we really need that for the purpose of standard making, let alone Internet Engineering? How about answering the classic privacy checklist: 1) How much personal information do we collect, and for what purpose? The rule here should be to collect the strict minimum necessary for the purpose. Pictures don't appear to meet that bar. 2) How do we process that information? Who in the IETF has access to it? 3) Do we make that information available to third parties? Under which guidelines? Again, there is a big difference between answering a subpoena and publishing on a web page. 4) How do we safeguard that information? Is it available to any hacker who sneaks his way into our database? 5) How long do we keep the information? Why? 6) How do we dispose of the expired information? These look like the right questions to the IAOC. -- Christian Huitema
RE: An Antitrust Policy for the IETF
This appears to be based on the view that an external legal process is amenable to the IETF's internal procedures. Of course, it isn't. Once there is a lawsuit, we are locked in to the procedures and authority of the courts and to the existing facts leading up to the lawsuit. Post-hoc efforts to evaluate whether we should have done something differently will be at the court's discretion, not the discretion of an IETF appeals group like the IAB or ISOC. I did not suggest that the IETF leadership only takes action once a lawsuit is filed. I observed that the particular lawsuit alleged that the SSO did not follow their own process. The IETF does have a process for resolving such issues: the internal appeal process. That process will alert the IETF leadership in time to take corrective actions if needed. Of course, plaintiffs could sue at any time, but they would have a very hard time arguing in a court of law that the IETF did not follow its process if they themselves did not use the recourse afforded by the IETF process. The lawsuit against the SSO argues a failure to act by the leadership. We don't know yet whether the lawsuit will succeed, but we can point out many avenues of actions open to the area directors or the IESG. They can of course send the offending draft standard to the WG. They can refuse publication. They can change the WG leadership. They can even dissolve the WG. This is the point where advice is useful. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: An Antitrust Policy for the IETF
Note that the suit does not complain about the 3GPP and ETSI rules. It alleges instead that the rules were not enforced, and that the leadership of these organization failed to prevent the alleged anti-competitive behavior of some companies. I believe that our current rules are fine. They were specifically designed to prevent the kind of collusion described in the complaint. Yes, these rules were defined many years ago, but the Sherman Antitrust Act is even older -- it dates from 1890. We have an open decision process, explicit rules for intellectual property, and a well-defined appeals process. If the plaintiffs in the 3GPP/IETF lawsuit had been dissatisfied with an IETF working group, they could have use the IETF appeal process to raise the issue to the IESG, and the dispute would probably have been resolved after an open discussion. Rather than trying to set up rules that cover all hypothetical developments, I would suggest a practical approach. In our process, disputes are materialized by an appeal. Specific legal advice on the handling of a specific appeal is much more practical than abstract rulemaking. -- Christian Huitema -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Joel jaeggli Sent: Thursday, December 01, 2011 8:56 AM To: Jorge Contreras Cc: Ted Hardie; IETF Chair; IETF; IESG Subject: Re: An Antitrust Policy for the IETF On 11/28/11 12:58 , Jorge Contreras wrote: On Mon, Nov 28, 2011 at 2:35 PM, GTW g...@gtwassociates.com mailto:g...@gtwassociates.com wrote: __ Ted, I like your approach of enquiring what problem we are striving to solve and I like Russ's concise answer that it is Recent suits against other SDOs that is the source of the concern Russ, what are some of the Recent suits against other SDOs It would be good to pin down the problem we are addressing There is FTC and N-data matter from 2008 http://www.gtwassociates.com/alerts/Ndata1.htm George -- one recent example is the pending antitrust suit by True Position against ETSI, 3GPP and several of their members (who also employ some IETF participants, I believe). Here is some relevant language from the Complaint: When or if that suit is concluded you may be able to divine whether the antitrust policy of either SDO was of any value. 100. By their failures to monitor and enforce the SSO Rules, and to respond to TruePosition's specific complaints concerning violations of the SSO Rules, 3GPP and ETSI have acquiesced in, are responsible for, and complicit in, the abuse of authority and anticompetitive conduct by Ericsson, Qualcomm, and Alcatel-Lucent. These failures have resulted in the issuance of a Release 9 standard tainted by these unfair processes, and for the delay until Release 11, at the earliest, of a 3GPP standard for UTDOA positioning technology. By these failures, 3GPP and ETSI have authorized and ratified the anticompetitive conduct of Ericsson, Qualcomm, and Alcatel-Lucent and have joined in and become parties to their combination and conspiracy. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call: draft-weil-shared-transition-space-request
I did share what I was smoking - it's called 'reality' :). Which reality? I think Randy is much more realistic! You are telling us that you want a /10 of private address space set aside because you cannot use the current allocation of private address space in RFC 1918. You tell us that the effect you want to achieve cannot be attained if the address that you use are also used by customer networks. But then, there is no mechanism whatsoever that would prevent customer networks from using the new /10 as soon as it would be allocated. Sure, you may put text in a RFC somewhere, but that is not a mechanism. Ergo, if we were to make that allocation, it will become unusable for your stated purpose in a very short time. I think that's not a very good idea. I would rather not see that allocation being made. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: An Antitrust Policy for the IETF
Ironically, it was concern about anti-trust suits which led to the creation of the ISOC, and the re-homing of the IETF under the ISOC, in the first place (back in the fall of 1989). Not only that. The current IETF rules were specifically designed with antitrust considerations in mind. The example at the time was not wireless positioning technologies, but a similar case involving boiler furnaces. The allegation was that a furnace maker somehow manipulated the standard process to exclude a competitor as non-compliant. A superficial reading of the two cases shows many similarities. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: reading on small devices, was discouraged by .docx
Do we have an official web page listing the timings of the ASCII text RFC discussions? It ought to tell us something about the state of the IETF... -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Plagued by PPTX again
In May of this year, patches were needed to mitigate ongoing PPT threats. http://technet.microsoft.com/en-us/security/bulletin/ms11-036 http://www.openoffice.org/security/cves/CVE-2010-2935_CVE-2010-2936.html http://blogs.technet.com/b/mmpc/archive/2009/04/02/new-0-day-exploits-using-powerpoint-files.aspx A quick look at http://www.adobe.com/support/security/ shows that PDF is not immune to security issues, and has at least as many bulletins out as PowerPoint. Complex presentations formats require complex code, and nobody is perfect. Just saying, but if we want to ensure that presentations are readable 50 years from now, and do not embed some kind of malicious code, we might stick to ASCII text, right? -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Plagued by PPTX again
I would not go as far as that, but forcing a format that is free from active content is probably a good start... I used to think that, until somebody showed me how to fuzz a JPEG file. No active content needed, just a syntax sufficiently complex to allow for coding mistakes or other oversights. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
I will be a bit more direct than Keith. There is no such thing as no leakage. These addresses will leak, no matter how well you believe you are isolated. Indeed, the issues posed by similar leakage were one of the main argument developed in RFC 3879, Deprecating Site Local Addresses. We see here a proposal to create site local IPv4 addresses for Internet providers. The IETF previously expanded significant efforts to deprecate IPv6 site local addresses. Why exactly do we believe that IPv4 site local addresses would be a good idea, when the consensus was that IPv6 site local addresses caused more harm than good? From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Monday, September 26, 2011 1:16 PM To: George, Wes Cc: IETF Discussion Subject: Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC) On Sep 26, 2011, at 2:15 PM, George, Wes wrote: From: ietf-boun...@ietf.orgmailto:ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org]mailto:[mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Friday, September 23, 2011 10:04 PM The problem is in the zillions of systems in the field that have assumptions about 240/4 wired into them, most of which either have no automatic upgrade mechanism, aren't set up to use it, or aren't being maintained. snip Honestly I'd guess that if vendors started changing their code today, it would be 10 years before 240/4 could be widely used in the field. WEG] See that's the point, I think we keep looking at this from a boil the ocean perspective. The question is not, could we use 240/4 as more global unicast space? as the ship sailed on that years ago when IETF apparently decided it was too hard to change and nothing should be done. The question is, if the space were unreserved, are there valid use cases where networks within a given administrative control might be able to make use of it? maybe. But I personally don't believe that such addresses won't leak out. I'd say if a network operator wants to make a case for it using 240/4, it can write up an Internet-Draft detailing how it would be used along with containment measures, and petition IETF to ask IANA to permit such use. The last thing that's needed is to open up that space for general use for anybody who thinks it's a good idea. And I sympathize with the notion that any use of the precious remaining reserved v4 space should somehow credibly promote IPv6 adoption. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
Not exactly to play devil's advocate here, but I don't think these are quite like site-locals. It seems like they're more like ISP locals. I know that is the proposition. But if an address space is somehow set aside, we have no mechanism to enforce that only ISP use it. So we have to assume it will be used by whoever feels like it. It was especially important to get rid of site locals in IPv6 because IPv6 was in very early stages of deployment, and any errors in its design would be magnified over time. It is also important to avoid mistakes during the transition period from IPv4 to IPv6. I understand that many actors are anxious and waiting for some kind of fix. This is a common scenario for making substantial mistakes... -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 6to4v2 (as in ripv2)?
6rd addresses a different problem than 6to4. 6to4 is a global solution, that relies on pretty much every native IPv6 provider deploying 6to4 relays. If these relays were really well deployed and reliable, 6to4 would allow any router with a native IPv4 address to provide IPv6 connectivity to its local users. That is, 6to4 relies on the kindness of strangers and allows uncoordinated deployments by end-users. 6rd is a local solution, that can be used by providers to easily deploy IPv6 tunnels over their existing IPv4 infrastructure. The provider controls the IPv6 prefix, which effectively defines a specific 6rd subnet. The provider also controls the deployment of relays between the 6rd subnet and the native Internet. There is no need to rely on the kindness of strangers. In a sense, 6rd is very similar to a tunnel broker deployment, with a key improvement and an important limitation. The key improvement is the ability for 6rd routers in the same domain to send traffic directly at each other. Local traffic stays local, does not need to be relayed by the tunnel servers or the 6rd relays. The key limitation is that 6rd assumes direct IPv4 connectivity between the participating 6rd routers, i.e. no NAT. 6rd is a very good solution for its intended usage, rapid deployment of IPv6 by IPv4 providers. But 6rd is not a replacement for the global, uncoordinated 6to4 deployment. Hosts that really need this kind of uncoordinated global solution will have to rely on Teredo if they cannot use 6to4. Whether that's a good thing is clearly a matter of debate. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Michel Py Sent: Friday, July 29, 2011 11:38 AM To: Rémi Després Cc: ietf@ietf.org; Keith Moore Subject: RE: 6to4v2 (as in ripv2)? Rémi Després wrote: 6rd is designed to offer native IPv6 prefixes across IPv4-only routing domains. There is a word for that: oxymoron. In French: oxymore. If it stops working when IPv4 is broken, it is not native. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-ietf-v6ops-6to4-to-historic (yet again)
After some discussion, the IESG is attempting to determine whether there is IETF consensus to do the following: - add a new section to draft-ietf-v6ops-6to4-to-historic - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that: I do not think this is a good idea, and I am certainly not part of the consensus. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Why ask for IETF Consensus on a WG document?
It seems that we have wide consensus to publish the advisory document, not so much for the 6to4 historic part. Can we just publish the advisory and be done with this thread? -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: one data point regarding native IPv6 support
From Noel analysis, it seems that a lot of the issues could be mitigated by a simple connectivity test. Have the 6to4 router perform a simple ping test through the tentative 6to4 relay, towards some well-known IPv6 host. Or an HTTP test, if we fear that ICMPv6 might be somehow tampered with. If the test succeed, then it shows that the path to that 6to4 relay is clear of firewalls and other obstructions. If the path is not clear, pick another 6to4 relay, or do not enable 6to4. Of course, this does not solve the problem of intermittent failures on the IPv4 path to the relay, e.g. due to congestion. It also does not solve the problem of routers advertising an IPv6 route to 2002::/16 and then failing to deliver the IPv4 packets. But this return problem is easily solved by IPv6 ISP deploying their own 6to4 routers, and thus avoiding dependencies on a generic path to 2002::/16. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Arguably, transitions technologies like 6to4 and Teredo have already achieved their purpose. My goal at the time, more than 10 years ago, was to break the chicken and egg deadlock between application developers and network administrators. That's why I spent such energy on making 6to4 easy to deploy, or defining Teredo. Transitions technologies convinced developers that applications could be developed for IPv6 without waiting for every network to be ready, and applications were indeed developed by Microsoft and others. Network administrators in the meantime started deploying IPv6, and the presence of applications arguably helped somewhat -- although I am sure network administrators add many other motivations. We are now observing a strong pushback, because massive use of tunneling technologies makes networks harder to manage. Wide scale deployment of self-configuring technologies makes levels of services less predictable, and errors are hard to correct. Self-configuring technologies rely largely on the good will of others, which is easier to find during a pioneering phase. Arguably, we are beyond the pioneering phase for IPv6. I understand Keith's point of view, but it is probably time to start progressively rolling back the transition technologies. 6to4 is the weakest of these technologies. It does not traverse NAT, it does not include configuration verification tests, and it uses asymmetric paths. It makes sense to start the rollback with 6to4. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
I don't see that public identity (of expert reviewers) is required for interactive discussion. Or would anonymous interaction fail a Turing test of some kind? Public identity is required for reviewer accountability. It is easy to imagine how withholding registration of some required numbers may delay a competitor's products. The best protection against shade is sunlight. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF 83 Venue
Wasn't the official definition of the meter also tied to Paris? The invention of the meter is indeed tied to Paris. The value of the meter itself is not. The meter was defined by scientists commissioned by the French revolutionary assembly, but it is not exactly tied to Paris. The original definition was 1/10,000,000 of a quarter of the Earth circumference, and the commission of scientists established the value by measuring an arc of the earth circumference between North of France and North of Spain. The unit was then materialized by a big platinum ruler kept in a locker in Paris. It is now defined in relation to the speed of light, itself set as 299,792,458 meters per second. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Poster sessions
In the old days, you would get a bar BOF by rounding up a few buddies and paying for the drinks. I suppose that you can still do that, and don't need to get the secretariat involved! -- Christian Huitema -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, January 10, 2011 11:13 AM To: Yoav Nir Cc: ietf@ietf.org Subject: Re: Poster sessions Lars has written a draft in response to bar BoFs you describe below: Considerations for Having a Successful Bar BOF Session http://tools.ietf.org/html/draft-eggert-successful-bar-bof-00 On Jan 10, 2011, at 3:47 PM, Yoav Nir wrote: Despite the name, a bar BoF today is very much lecture-style. You have a presentation and a time for questions. There's really very little room for actual discussion (which supposedly happens later in some mailling list). A poster session allows for conversation with the I-D author, which may or may not lead to better results. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-turner-md5-seccon-update-07.txt (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC
The issue would be a whole lot easier to resolve if we had an agreed upon algorithm for the non security usages. CRC64 comes to mind. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] Sent: Wednesday, December 08, 2010 12:08 PM To: Francis Dupont; l.w...@surrey.ac.uk Cc: w...@mti-systems.com; i...@ietf.org; ietf@ietf.org Subject: RE: Last Call: draft-turner-md5-seccon-update-07.txt (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC The logic doesn't make sense in this position. Crypto modules can't use MD5, thus no protocols at all should use MD5. From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Francis Dupont [francis.dup...@fdupont.fr] Sent: Wednesday, December 08, 2010 9:55 AM To: l.w...@surrey.ac.uk Cc: w...@mti-systems.com; i...@ietf.org; ietf@ietf.org Subject: Re: Last Call: draft-turner-md5-seccon-update-07.txt (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC I have a concern about no security usages of MD5 for practical reasons: in some environments, including US Gov, crypto implementations (e.g., FIPS 140-2 HSMs) are required to not support MD5 so you can have to choose between a compliant application and a conformant crypto, for instance for DNS TSIG... So IMHO it is still a good idea to avoid MD5 in any uses, even when it is still far to have been proved insecure or for an use which is not about security. This could be caught by the DEPRECATED keyword in the registry but this registry doesn't seem to have usage entries?! To conclude I am fine with the implicit conclusion of the I-D to not use MD5 or HMAC-MD5 in new protocols. Thanks francis.dup...@fdupont.fr PS: I am the gen-art reviewer for this document too. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: US DoD and IPv6
any design for architecural change (e.g. introducing separation of location and identity) is going to be somewhat ugly, because we don't have a clean sheet of paper to work with. Location independent identifiers can be introduced at the transport or application layer, without having to change the network infrastructure. There is nothing to prevent researchers or application developers to design a transport that sits on top of IPv4/IPv6, or even on top of UDP, and manage location independent identifiers. This is the classic overlay play, at the end of which IPv6/IPv4 addresses, or address+port pairs, are redefined as mere lcators. Obviously, this only works for new applications, or new application releases. But if application developers really believe they will benefit from the split, they can do it. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF Logo Wear
Classic: IP over everything (dog optional) -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark Nottingham Sent: Monday, August 16, 2010 8:05 PM To: Fred Baker Cc: wgcha...@ietf.org; ietf@ietf.org Subject: Re: IETF Logo Wear That's going to be hard to fit on a t-shirt, Fred. *ducks* On 17/08/2010, at 8:34 AM, Fred Baker wrote: IEN 111, August 1979. The preface reads: This document describes the Internet Protocol. There have been three previous editions of this specification, and the present text draws heavily from them. There have been many contributors to this document both in terms of concepts and in terms of text. Jon Postel Editor I suspect that, as editor, he would blanch a bit at finding anything there attributed specifically to *him*; he would have said - and on occasion did say - I was there, but would go on to point out that there were many contributors and many contributions. That said, it is the first instance I can find of the Robustness Principle: The implementation of a protocol must be robust. Each implementation must expect to interoperate with others created by different individuals. While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior. That is, it should be careful to send well-formed datagrams, but should accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear). The comment, in various forms, is repeated in IENs 112, 123, 124, 128, and 129, and in RFCs 760, 761, 791, and 793. On Aug 16, 2010, at 3:09 PM, Sean Turner wrote: I like: Be conservative in what you send and liberal in what you accept Jon Postel I'm sure somebody who has been around longer than me can offer up a date ;) spt Fred Baker wrote: There's no place like ::1 On Aug 16, 2010, at 2:01 PM, Philip Nesser wrote: We obviously need an IETF branded one of these: http://www.cafepress.com/+theres_127001_infant_bodysuit,88172 --- Phil On Mon, Aug 16, 2010 at 8:26 AM, IETF Administrative Director i...@ietf.org wrote: All; At the request of the community the IAOC and the IETF Trust have approved the establishment of an online store from which the community can buy IETF logo wear. The store is at CafePress at: http://www.cafepress.com/ietf The store is maintained by the Internet Society and is expected to generate a very modest income, which will be used to offset IETF operational expenses. Suggestions for products or designs may be directed to Steve Conte, co...@isoc.org. Shouldn't everyone in your family have an IETF logo wear t-shirt? Ray Pelletier IAD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: T-shirts?
- The graphics use a unique brown that we are unable to duplicate. Changing the brown of the background causes the letters to fade considerably (since they're light colors) - More importantly, the online vendor only allows two-sided printing (front and back of shirt) on light colors only. If we have a dark colored shirt, then they only let printing on the front. Can we make sure that the shirts are ASCII only? -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Make the Internet uncensorable to intermediate nodes
Agreed. However, it could still be useful towards that aim, on a small-group scale, to have a communications protocol (or suite thereof) that would be *resistant* to censorship, at least of the kinds currently common. Most likely, something that would serve as a carrier for something else -- and be more inconspicuous than IPsec. IPsec is only conspicuous because it is not used very much. In fact, that was the whole point Phil Zimmerman was making with respect to encryption. You want everybody using encryption for all sorts of things, otherwise the few who use it because they really have something to hide will be conspicuous. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ogud-iana-protocol-maintenance-words (Definitions for expressing standards requirements in IANA registries.) to BCP
If the real reason for this draft is to set conformance levels for DNSSEC (something that I strongly support), then it should be a one-page RFC that says This document defines DNSSEC as these RFCs, and implementations MUST support these elements of that IANA registry. Then, someone can conform or not conform to that very concise RFC. As the conformance requirements change, the original RFC can be obsoleted by new ones. That's how the IETF has always done it; what is the problem with doing it here? Second that. Let's not overload the registry. As Edward Lewis wrote in another message, The job of a registry is to maintain the association of objects with identities. If the WG wants to specify mandatory-to-implement functions or algorithms, the proper tool is to write an RFC. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
XML2RFC and 2010?
I am trying to prepare a draft using XML2RFC online, and I am getting the error xml2rfc: error: I can't synthesize a date in 2009 around input line 58 Context (format: file_basename:line_in_file:#elem_num:elem ...): CGI5001.1:53:#1:rfc category=std docName=draft-ietf-behave-address-format-03.txt ipr=trust200902 obsoletes=2765 Any idea why? -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
What is this with these confirmation messages?
All IETF mailing list seem to now require this %!$# confirmation procedure. This particular message was rather ironic; I was sending a request to postmas...@ietf.org! Who decided to implement this filtering, and why did they do such a poor job of it? Whose -Original Message- From: ietf-act...@ietf.org [mailto:ietf-act...@ietf.org] Sent: Thursday, December 24, 2009 1:20 PM To: Christian Huitema Subject: Confirm: ietf-act...@ietf.org:phQqLmSzPbBA:BttiZVJDKqxGAJxkqjzyRLPoJnA_T9FrS9ksVw Confirmation of list posting -- confirmation ID: phQqLmSzPbBA The ietf.org mailing-list server has received a list posting from huit...@microsoft.com to ietf-act...@ietf.org with the subject 'Why am I receieving this message?' As the sender address isn't subscribed to the list, and has not been confirmed earlier, we have to request a confirmation of the address. To confirm the address, send a message to ietf-act...@ietf.org, with the same subject line as this message. (Simply sending a 'reply' to this message should work from most email interfaces, since that usually leaves the subject line in the right form. The reply's additional Re: is ok.) If you do not wish your posting to the list to go through, simply disregard this message. Questions to postmas...@ietf.org. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Most bogus news story of the week
The trick here is that the question is not so simple (or the answer to the question is not so simple). I was myself working with launching Internet in Europe from -87 and sure, we had to pay quite a lot to get our first connection to ISPs (then only in the US) so I am pretty sure I have been in the situation you talk about. That we thought the situation was unfair. Back in 1988, the cost a 64kbps connection between the south of France and New Jersey was about $50K per year. The price of the connection between the south of France and Paris was about the same. Technology drove down the cost of the transatlantic connection. Deregulation drove down the price of the French connection. Deregulation also boosted the availability of the Internet in France. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Decentralising the DNS
From: Bill Manning, Friday, June 12, 2009 10:32 AM On Fri, Jun 12, 2009 at 03:55:05PM +0100, Sabahattin Gucukoglu wrote: Silly question, I'm sure - any chance of putting the DNS into a gigantic DHT and spreading the entry nodes liberally about the planet? Cheers, Sabahattin PS: No political agenda implied. been proposed quite a few times over the years in one form or another. It is indeed technically possible to develop a worldwide distributed service -- check http://en.wikipedia.org/wiki/PNRP for an example. However, a pure P2P implementation immediately bumps against the question of authority. Who gets to publish the address for www.example.com? I you allow anybody, the system can become really unreliable. If you request a certificate to certify the publishing, you get all the generic PKI issues, e.g. who to trust, etc., and you end up with a system that is not much more P2P than the DNS. The only secure solution that we could deploy uses large numbers instead of names, where the number is essentially a hash of a self-signed certificate. That works, for some definition of working: if you know what number to retrieve, you will get an authoritative answer. But that means using large numbers instead of short friendly names, and thus is not very user-friendly. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: DNSSEC is NOT secure end to end
Yes, security of DNSSEC is totally hop by hop. Thus, you imply a definition of hop by hop along digital signature relationships. Indeed, DNSSEC security is limited to the weakest link along the chain from the bottom to the top of the DNS hierarchy. Nothing new there. I don't think any DNSSEC expert ever claimed differently. Even in the presence of the attack by a trusted party, there are still huge differences between DNSSEC and transport-hop-by-transport-hop security. Transport based solution, SCTP or TCP, are open to attacks by any party in the path between two hops -- NAT routers come to mind. DNSSEC is immune to such attacks, a big advantage in practice. Also, it is actually possible to improve on DNSSEC by introducing additional knowledge. If two domains have an establish relation, their servers can memorize the relevant public keys. If a host has a relation with a domain, it can memorize that domain's public key. This kind of peer-to-peer improvement makes the domain-to-domain or host-to-domain DNSSEC service immune to attacks by nodes higher in the hierarchy. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mif] WG Review: Multiple InterFaces (mif)
(2) There is no way that these decisions can be made solely at the transport or application layer, because source (and to a lesser degree destination) address selection is tightly tied to the first-hop forwarding decision. The outbound interface, source address and default router all have to be selected in a coordinate process, to avoid sending traffic that will be discarded on the outbound path, due to router filters. Actually, applications can to do that today, using the socket API, if the stack implements the strong host model. The application just needs to bind the socket to a specific IP address. Doing that ensures that packets sourced by the application will use the specified address, will go out through the interface corresponding to that address, and will use the default gateway associated with that interface. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] FW: Last Call: draft-ietf-behave-nat-behavior-discovery (NATBehavior Discovery Using STUN) to Experimental RFC
So most people miss this, which may mean it needs to be clarified more somehow, but the algorithm section is actually not normative. Maybe, but the draft starts with 20 pages of algorithm discussion, and follows with 3 pages of attribute description. I would be much more supportive if the draft could be summed up as this draft defines 6 STUN attributes and 2 response codes that can be used when characterizing the attributes of NAT. It gives examples of possible algorithms that justify the allocation of the attributes. It provides security guidelines that prevent misuse of the attributes. You probably don't need more than 5-6 pages for that. I believe the authentication and CACHE-TIMEOUT mechanisms in the draft are sufficient for preventing DoS, and there was consensus for that the last time the change was made and presented a few meetings ago, but welcome any further comments on the issue. Actually I have a comment there. The XOR-RESPONSE-TARGET attribute has a high potential for abuse, since it allows clients to instruct servers to send packets to arbitrary targets. I understand that requiring authentication helps, but that leaves the door open for failures to implement authentication properly in servers, or failures to secure credentials properly in clients. Again, I would be much more supportive if this attribute definition was removed from the draft. In fact, I believe that XOR-RESPONSE-TARGET is not needed. Most of the tests can be performed using the CHANGE-ADDRESS attribute, which does not have the same potential for abuse. Besides, if you really want to send packets from outside the local network towards arbitrary destinations, you can use TURN. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call for draft-housley-tls-authz
While I agree (and strongly so), there is lots of precedent for the IESG rejecting parameter registrations because of distaste for a particular extension, presumably in the hope that no registered value will imply the unpopular extension idea goes away. There are indeed lots of precedents for this. And speaking as someone who, as media types reviewer, has had had to clean up the mess as best I could when we were overly restrictive with one of these things, there is also precedent that doing this can be a REALLY bad idea. I agree with Ned. The main purpose of the registry should be to document what is out there, not to act as a gatekeeper. Even when a protocol is not a full standard, having a public documentation is useful. Documentation enables filtering, monitoring, even debugging. By the way, other institutions have found ways to decouple number collision avoidance and registration. IETF protocols use short fields for parameter identifiers, small number spaces that effectively mandate registration in order to avoid collisions. This is an engineering decision that trades administrative hassles for shorter messages. It is not the only choice. Other design have used Object Identifiers (SNMP, ASN.1), or Universal Resource Locators (most W3C protocols). OID and URL requires some amount of registration, to obtain a node in the hierarchy, but allow for decentralized allocation of identifiers in these hierarchies. If you don't want to use a hierarchy, you can also use GUID, essentially a 128 bit random number. Open extensibility with OID, URL or GUID is, in my opinion, a better design than relying on registries for number allocations. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
i disagree. dns-based load balancing is an unfortunate overloading and should never be done. RFC 3484 is correct as it is. Why is it right for topology-ignorant clients to override topology- aware DNS servers based on wishful thinking about RIR address allocation policies? The order of records in a DNS response is, at best, a hint. Relying on it as if it were a mandate to clients is a gamble. It is quite legitimate for clients to consider the entire list of addresses and try to pick the best ones, based on their knowledge of topology. We may argue whether the specific algorithm in RFC 3484 is the correct one, and I hope that future clients will implement something smarter than prefix matching. But if service operators want to balance load on their servers, they need to consider something a bit more sophisticated than merely reordering the records in the DNS response... -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Proposal to create IETF IPR Advisory Board
This discussion of IPR seems to be running in circle. Can't we switch to something else, e.g. whether RFC could be written in some other format than ASCII text? -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: The internet architecture
I would agree with this, except I defer to the 'get down off an elephant' principle. If both points of attachment are bound to a single transport level entity, then it ought to be relatively easy, and not involve the routing at all, to detect that both points of attachment lead to the same entity. It ought to be, but unfortunately we have confounded the transport entity namespace with the network entity namespace with the point of attachment namespace. Not really. Many applications are actively managing their network connections, and for a good reason. A network connection is not an interface to an abstract unified network. On the contrary, a network interface implements a contract with a specific network. Take the example of a laptop with Bluetooth, Wi-Fi, WIMAX and 3G. Four connections, with four different providers. Wi-Fi, through the access point, communicates with a broadband provider, maybe a cable company such as Comcast. WIMAX communicates with the Internet through a wireless provider, maybe Clearwire. 3G also offer some kind of Internet access, possibly through a different provider such as ATT. And Bluetooth typically does not communicate with the Internet, but provides access to some local devices. You will note that the different providers have different rules for managing traffic. Behind each interface lies a different contract, a different type of service. Is it possible to manage all these interfaces as if they were a single abstract point of attachment? Maybe. That would require a common management system. Can that management system be part of the network? Frankly, I doubt it. The management system will have to make arbitration between different services, deciding which part of the traffic goes which way. These decisions have economic consequences. Do you really believe that different providers will delegate these economic decisions to some kind of cooperative distributed system? If that was realistic, we would have network wide QOS by now... On the other hand, the end system is in a very good position to implement these arbitrations. It has direct access to the requirement of the applications, and to the terms of each specific interface contract. Moreover, it can actually measure the quality of the offered service, allowing for informed real time decisions. We can debate which part of the end system should implement these decisions, whether it should be the application or a common transport layer. I can see arguments either way. But the business reality essentially precludes an implementation in the network layer. Even if we did reengineer the network layer to implement a clean separation between identifiers and locators, the business reality will still be there. We will end up with separate identifiers for the different provider contracts, and applications, or the transport layers, will have to arbitrage between these contracts. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: The internet architecture
It ought to be, but unfortunately we have confounded the transport entity namespace with the network entity namespace with the point of attachment namespace. Not really. Many applications are actively managing their network connections, and for a good reason. A network connection is not an interface to an abstract unified network. On the contrary, a network interface implements a contract with a specific network. It seems to me that you're agreeing with me. It's exactly because the three namespaces I mentioned are mashed together by TCP/IP that applications have to do what you describe, rather than just saying open a connection to Christian's laptop. If Christian's laptop is the transport name space, and if the network entity namespace use different network entity names to designate the various network contracts, then, yes, we probably agree. Although I am not sure that we should place too much emphasis on the name of physical entities like Christian's laptop. What if the application process migrates from my laptop to my desktop? -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: RFC 5378 representation
On Thursday, December 18, 2008 3:10 PM, Fred Baker wrote: So, having just cleared this note with the Trustees, sending it in, and forwarding the note to the IETF list, I observe http://trustee.ietf.org/docs/Contributor_Non-Exclusive_License_RFC5378.pdf. Fred, Some of these RFC were written when you were working for ACC. This is a fairly common situation among us. I have written RFC as an employee of INRIA, Bellcore/Telcordia, and Microsoft. Just curious, did you check with whoever bought ACC's intellectual property rights? -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
You can improve any technology you want, modulo IPR -- that's not the point here. The problem is taking existing copyrighted text and using it as a base for describing your technology. That's indeed the problem we stumbled upon years ago. Suppose that a contributor has written a complete description of technology X, getting it published as a 100 pages RFC. A remarkable feat, and a great contribution to the community. A few years letter, the working group realizes that they like the technology, but would like to change a couple options. That normally translates into changing a paragraph or two, resulting in a new RFC, more than 90% identical to the previous one. Suppose now that for whatever reasons, the original author disagrees with the changes, or with the new management of the working group, or with the new editor. People are human, these things do happen. IANAL, but my understanding at the time was that the original copyright still applied to the original text, and that the working group would be left with only bad options. They could issue a delta RFC that only contained the modifications, but that is somewhat confusing for the readers. Or they could undertake a complete rewriting of the standard, but that takes a long time and is also prone to errors and confusion. This is very much why we got the statement on copyrights in RFC 1602, in 1996. You will notice that copyrights were only mentioned as something we might need to worry about later in the appendix of the previous rules, RFC 1310 published in 1992. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Lack of need for 66nat : Long term impactto applicationdevelopers
Actually, rather than tunneling, have we seriously consider flat host based routing in a corporate network? A combination of DHT and caching technologies ought to make that quite scalable. I've used large, flat networks, and lived to regret it Do we have a documentation somewhere about the evils of flat networks? Do we know which are links to specific technologies, e.g. the convergence time of spanning trees, and which are tied to the subnet model, e.g. multicast storms? It seems to be a classic case of engineering trade-offs, and mitigation of specific issues... -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Lack of need for 66nat : Long term impactto applicationdevelopers
GSE/8+8 gives us the ability to manage the addresses we exchange in routing down to a number of prefixes on the order of (eg equivalent to a small multiple of) the number of autonomous systems. Not really. Or rather, it will, at the following costs: - all IPv6 implementations must be rewritten - need an IPv6-GSE transition strategy but unlike v4-v6 addresses look the same - still renumbering necessary when switching ISPs - identity theft trivial unless we implement id-locator security protocols - no multihoming without extra protocols to detect and repair failures GSE/8+8 also does not achieve topology hiding, not if the mapping between internal and external /64 is a one-one. Of course, you could smash multiple internal subnets to a single /64 external view, but then you would probably need a new duplicate address detection algorithm to avoid conflicts, not to mention recognize cases of a single host using the same host ID on multiple subnets. Of course, Iljitsch points an interesting issue. If NAT66 behaves exactly like, say, NAT 64, then why would the organization bother to use IPv6 rather than sticking with net 10? -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Lack of need for 66nat : Long term impactto applicationdevelopers
I'm not sure I believe in the need for topology hiding. But if I did, on v6 I'd just allocate a separate subnet or group of subnets for external access. If really necessary, have such hosts set up IP over IP or L2TP tunnels to a concentrator; that will make this external access net look flat. That idea has been advanced quite a few times, but there is not a whole lot of code written or products deployed. There are a few interesting issues, e.g. the cost of tunneling versus in terms of overhead or management, or the deployment of adequate source address selection policies. Actually, rather than tunneling, have we seriously consider flat host based routing in a corporate network? A combination of DHT and caching technologies ought to make that quite scalable. Of course, Iljitsch points an interesting issue. If NAT66 behaves exactly like, say, NAT 64, then why would the organization bother to use IPv6 rather than sticking with net 10? Services like Microsoft DirectAccess? Direct Access certainly does not require that enterprises deploy NAT66... -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Ltru] Possible RFC 3683 PR-action
Does the IETF have a policy regarding misrepresented identities? In the particular incident, it is assumed that the person using the name of a famous French aviation pioneer is in fact someone else. On the one hand, using pseudonyms is a form of free speech. But on the other hand, in a standard setting body, hiding identities is not necessarily something we want to encourage. What are the implications for our standard process? What about copyrights and patents? -- Christian Huitema ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Confirming vs. second-guessing
And in order to make the confidentiality issue more concrete (ie, real) would folks offer some examples of what falls under it. I accept the nomination of area director. The current area director, Mr. J. Sixpack, has been attempting to impose his opinion that beer should contain rice. This is causing a rift in the working groups within the area. I would follow the area consensus that we should outlaw rice in beer and thus my appointment as new area director would achieve peace and harmony within the area. Why should such a statement be confidential? -- Christian Huitema ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 NAT?
You know of an O/S that is not vulnerable to malware attacks? Please let me know the name, I haven't encountered one professionally since I was using OpenGenera in '95 and that was only secure because we had a more or less complete list with the names of every person who had ever successfully managed to learn the beast. Very few software products can be considered perfect. However, NAT and basic statefull firewalls only protect against a specific category of attacks, the arrival of unsolicited connection requests through the network. Most mainline operating systems have built-in protection against such attacks. Windows XP-SP2 and Windows Vista certainly do. They come with a built in firewall that will, by default, prevent incoming traffic on all ports. I understand that recent Linux distributions and recent versions of OS/X have similar protections. Attacking ports by sending random packets is very much a 2003 story. Modern malware typically works by exploiting users' naiveté, bugs in document parsers, or a combination of both. An example of user naiveté would be to ask users to download a special media player to look at frolicking bodies. An example of exploiting document parsers would be to lure users to visit a malevolent web site, and have they open a booby trapped image or movie. The typical NAT or stateful firewall offers no protection against document parsing bugs. That is a good thing. If firewalls tried to do that, they would have to incorporate a large amount of document parsing code, and would most probably become a target for their own parsing bugs. Of course, no amount of electronics will protect against users intent on downloading a very special media player... -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 NAT?
I don't know for Linux, but the normal configuration of a print or file sharing service in a Windows home network would be to only listen on the local network, which makes it immune to arrival from the network. The connection simply will not be established. Of course, the simple single network solution does not work in enterprises. There are multiple solutions available to limit access to enterprise services, for example server and domain isolation using IPSEC (http://technet.microsoft.com/en-us/network/bb545651.aspx). This is actually what Microsoft does use in its internal network. There are multiple offers for parental control services, e.g. built in Windows Vista (http://blogs.msdn.com/uac/archive/2006/04/06/570560.aspx). Of course, if you are simply looking at incoming traffic load, then clearly routers can play a role by implementing a form of rate limiting. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip Sent: Friday, February 15, 2008 10:10 AM To: Christian Huitema; Spencer Dawkins; Iljitsch van Beijnum; [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: RE: IPv6 NAT? Ok you tell me in less than a page how someone can use just those tools to be sure that their network is going to be safe when a network worm comes in an clobbers the print server running Linux 6.2 The problems are much harder than anyone knows to solve today. How do I set an acl on my home server to be sure that the kids cannot watch unsuitable movies stored on it from their machines while being able to watch them myself? Try it before you respond. And that is one of the better user interfaces. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Christian Huitema [mailto:[EMAIL PROTECTED] Sent: Friday, February 15, 2008 09:37 AM Pacific Standard Time To: Hallam-Baker, Phillip; Spencer Dawkins; Iljitsch van Beijnum; [EMAIL PROTECTED] Cc: ietf@ietf.org Subject:RE: IPv6 NAT? You know of an O/S that is not vulnerable to malware attacks? Please let me know the name, I haven't encountered one professionally since I was using OpenGenera in '95 and that was only secure because we had a more or less complete list with the names of every person who had ever successfully managed to learn the beast. Very few software products can be considered perfect. However, NAT and basic statefull firewalls only protect against a specific category of attacks, the arrival of unsolicited connection requests through the network. Most mainline operating systems have built-in protection against such attacks. Windows XP-SP2 and Windows Vista certainly do. They come with a built in firewall that will, by default, prevent incoming traffic on all ports. I understand that recent Linux distributions and recent versions of OS/X have similar protections. Attacking ports by sending random packets is very much a 2003 story. Modern malware typically works by exploiting users' naiveté, bugs in document parsers, or a combination of both. An example of user naiveté would be to ask users to download a special media player to look at frolicking bodies. An example of exploiting document parsers would be to lure users to visit a malevolent web site, and have they open a booby trapped image or movie. The typical NAT or stateful firewall offers no protection against document parsing bugs. That is a good thing. If firewalls tried to do that, they would have to incorporate a large amount of document parsing code, and would most probably become a target for their own parsing bugs. Of course, no amount of electronics will protect against users intent on downloading a very special media player... -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: Deployment Cases
However we do need to have a basis for believing that the work we are doing will actually get used. We went through that many times. The best way we have found so far is to verify that the proposed working group has a sufficient constituency. This has the advantage of not requiring economic or business judgments from the IESG. After all, one should assume that the participants who are expressing interest did their homework, business plans and the like. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 Outage Planned for IETF 71 Plenary
Disrupting a meeting funded for a different purpose will/would be an offensive colossal waste of resources. I think some disruption is in order. The stronger argument I have heard against the proposed IPv6 interlude is that it is not compatible with the services loaded on participants' laptops by their enterprise's IT department. Fine. So the participant will come back and send a note to their IT department, complaining that lack of IPv6 support forced them to stop reading corporate e-mail for an hour. Better warn them now. IT department are notoriously conservative, and it takes warnings like that to get them to move. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 Outage Planned for IETF 71 Plenary
Maybe reports of the DNS is broken when you do go to pure IPv6 are more valuable than you can only go to IPv6 if you jump through these hoops that only advanced Internet users can do. Is the IETF afraid to eat it's own food? Or is it willing to do what's necessary (in the interim) to adjust to the new cuisine? Our networking team at Microsoft did run an IPv6 only trial during the development of Windows Vista. Volunteers only. The volunteers would disable the IPv4 stacks on their PC, and then attempt to go on with their normal work, both for internal applications such as corporate mail, file servers, or intranet servers, and for external applications, mostly web based. It worked, but it had to rely on a set of transport proxies for those internal applications that were not yet IPv6 ready, and of course web proxies for internal access. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: mini-cores (was Re: ULA-C)
Well, a start would be a connectbyname() API call that takes care of name-to-address mapping and trying different addresses until one works. Something like WSAConnectByName? From http://msdn2.microsoft.com/en-us/library/ms741557.aspx: The WSAConnectByName function establishes a connection to a specified host and port. This function is provided to allow a quick connection to a network endpoint given a host name and port. This function supports both IPv4 and IPv6 addresses. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Symptoms vs. Causes
There are a large number of protocol designs--even existing protocols--which are compatible with the general paradigm of user U proves possession of password P to server A without giving A a credential which can be used to impersonate U to server B. HTTP Digest, TLS-PSK, SRP, and PwdHash all come to mind. The difficult parts are: (1) putting a sensible UI on it--including one that isn't easily spoofed (see the extensive literature on how hard it is to build a secure UI. (2) Getting everyone to agree on one protocol. Please add: (3) The chosen solution is immune to dictionary attacks. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv6 addresses really are scarce after all
Assume we agree on the needed functionality. It is hard to disagree and many of us have seen the need to isolate some people and apparatus from others, and to assign different capability to them, for many years. People want security, and the threats that Michael mention are real: children spying on the parent's traffic, guests abusing the access to do something illegal on the Internet. But subnets are not a particularly efficient way of solving these threats. Take the issue of guests abusing the privilege and engaging in illegal action. The concrete risk is that men in black will knock at your door and ask about said actions. Picture yourself arguing that it obviously wasn't me, because the packets come from the network that I provide to my guests. The men in black will not be impressed, since you obviously have access to all the networks in your house. Your only defense will be to rat a specific guest, supposing of course that you are so enclined. Subnet or no subnet will no help you do that. Access control and logs will help, but these are not tied to subnets. Consider then the attacks between computers on the same network. Michael mentioned traffic snooping. But modern Wi-Fi network are protected against that already. They negotiate different per-session keys. Even in promiscuous mode, the Wi-Fi card does not see the unicast traffic of the other stations in the network. In home networks, the key is derived from an initial 4-ways handshake, secured by a pass-phrase. Most deployments use a single pass-phrase today, so teenagers could indeed develop tools to crack the exchange. But nothing prevents using different pass-phrases for different group of users. The other risk are the active attacks between connected computers. However, as John pointed out, there is lot of demand for connectivity between computers in the home. Many people have tried to engineer network topologies that follow organization or authorization boundaries, but the mostly that makes your network expensive to run without really solving the issues. Also, ultimately, all forms of topology based control rely on the security of the home router. Do you really believe that a teenager who is clever enough to hack into Wi-Fi access protections will not also be able to hack into the home router? If we want actual protection, it is probably much easier to use end to end security. And in your own house, you might consider forms of social control, as in OK, you hacked my computer, give me the keys of your car... Frankly, I don't see users managing subnets any time soon. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv6 addresses really are scarce after all
From an architecture point of view, I believe there are only two interesting delegation lengths, /48 and /64. My rationale is that there really are two kinds of networks: big and small. The definition of a small network is pretty much single subnet. Yes, I understand very well that the average home of the future will have a mixed wiring. Of course, my own home does have Ethernet and Wi-Fi. In the not so distant future, it will have several Wi-Fi networks operating on different frequencies, some form of power-line networking, and some rooms may have their own high speed wireless wiring using UWB or some similar technology. But I am pretty much convinced that all of these will be organized as a single subnet. There are multiple trends pushing for the simple subnet. Most home networking technologies have a deeply engrained single subnet assumption, and will simply refuse to establish connections out of the subnet. Wireless technology is evolving towards mesh, in which the wireless segments are bridged on demand following the vagaries of radio propagation and the movements of devices. Mesh pretty much assumes that the IP address remains unaffected by low level topology changes, which means a host will not change subnet because it just switched to a different radio. Users will keep finding it easier to deploy self forming layer 2 networks than manage the additional complexity of subnets. Of course, the technology has limit today. Subnet sizes are limited by the efficiency of the spanning tree algorithm, or by the quadratic scaling effect of multicast operation. But these limits can be pushed. The spanning tree algorithm can be replaced by something more efficient, and indeed will be as the mesh technology evolves. Multicast overhead can be reduced with appropriate filters. It can also be reduced if applications switch from simplistic multicast schemes to more elaborate technologies, e.g. distributed hash tables. These evolutions will be naturally driven by market demand, as homes get equipped with more and more devices, all the way to the IPv6 light bulb. The single subnet is well served by a /64 prefix. Devices can be built in factory with unique /64 numbers. When there are privacy issues, hosts can pick random 64 bit numbers and not be really worried about collisions, at least not until there are billions of hosts in the subnet. Of course, the home may well get several /64 prefixes, for example because it is multi-homed. But there is no particular need to aggregate these prefixes. Indeed, if the goal is multi-homing, the different prefixes will come through entirely different delegation chains. If the granular level is /64, then what should the next level be? Well, as far for now, /48 makes a lot of sense. It is enough for most enterprises, allowing them to delegate /64 to each interesting subnet. I would assert that the smaller value, /56, is too small. It is not sufficient in most cases, and it also unduly increase the registration load in the registries. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-ietf-v6ops-natpt-to-historic-00.txt
From: Noel Chiappa, Monday, July 02, 2007 6:08 AM From: [EMAIL PROTECTED] (Jun-ichiro itojun Hagino) if NAT-PT is to be made historic due to the claims presented in the draft, all of the NAT related documents have to be made historic ... and all of the NAT traversal documents .. has to be banned at once. [EMAIL PROTECTED] 911 The irony of that email address, appended to that message, is pretty good. Noel :-) Maybe someone should pause and consider why the IETF publishes specifications, or informational documents. Over the last 15 years, I have seen a drift of attitude, basically from engineering to a policy making. In the old engineering attitude, working groups were created because several like-minded engineers wanted to develop some function, or protocol. It was important for them to get together, so they could voluntarily agree on the details. If they did not, each would develop their own version, and there will be no interoperability. The result was documented in a set of RFC, so that whoever wanted to develop a compatible product could. IANA registries are used to ensure that when options arise, the options are numbered in an orderly manner. In the policy making attitude, working groups are created to control evolution of a particular function. The working group members are concerned that someone else might be implementing something harmful to the Internet. Their goal is not so much to develop products as to ensure that non-conforming products do not get developed. IANA registries are used to control extensibility of the resulting protocols, to make sure that bad options never get a number. In short, the IETF evolved from an informal gathering where engineers will agree on how to do things, to a reactive body that mostly aims at controlling evolution of the Internet. Is that really what we want? -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Warning - risk of duty free stuff being confiscated on thewaytoPrague
Maybe the airlines should simply shut down the duty free shops and send every passenger a discount coupon for $10 off a bottle of booze bought in their local liquor store. The policy is not specific to duty free. I was caught by it last month during a domestic trip in France. I had bought Armagnac from a local producer in the South of France, and was flying bag to Paris. Luckily, the registration mentioned the policy, and gave me time to stuff the bottle in my checked-in suitcase. The rule is simple: you cannot bring a container greater than 100 cc, about 3 oz, in an airplane through security. You can bring several containers of lower capacity than 100 cc, but the combined capacity of these container is limited; they have to all fit in a 1 liter plastic bag. The theoretical rationale for the rule imagines terrorists mixing products in a bottle. Each of the products is supposedly harmless, or at least not detected by airport security machines, but the combined result is explosive. By limiting the capacity of the container, the security folks hope to limit the potential of any device fabricated aboard the plane. Those of us who have toiled through chemistry labs may find the all idea somewhat theoretical. You may remember the dire warnings of the teachers about what happens if you fail to control a reaction, if you let it overheat, or if you shake it a little too much. You may consider the improbability of repeating the experience in the shaky cramped space of an airliner's toilet. But then, you would not have the same mindset as the airline security folks. Given the rationale, I am still puzzled by the fact that bottles bought after the security check are allowed on board. Probably has to be a compromise between air traffic security and airport economics. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
Next slide, yes, CRAM-MD5 is *not* designed for that attack. That is my point. We should not, in 2006, standardize security methods that are not robust against a fairly well known attack. Adding a prose version of your slides 3..6 and 13 to the security considerations of a 2195bis could improve it. Do I miss a clue, or has DIGEST-MD5 essentially the same issue ? DIGEST-MD5 is somewhat more robust than CRAM-MD5 because it incorporates protection against chosen plaintext attacks. If an attacker can fake a server and send a chosen challenge, then the dictionary attack can be accelerated with a pre-computed catalog. However, current dictionary attacks do not need to rely on pre-computation, since a modern PC can compute more than a million MD5 hashes per second. So, yes, DIGEST-MD5 has essentially the same issue. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
From: Kurt D. Zeilenga [mailto:[EMAIL PROTECTED] At 04:07 PM 9/7/2006, John C Klensin wrote: I think we have a small misunderstanding here. Let me say more clearly and briefly My message was intended to clarify why the SASL WG is pursuing an Informational recommendation for its RFC2195bis work and to redirect any comments specific to this work to the WG's list. Well, if I remember correctly, there was ample discussion of this topic during the IETF meeting in Paris -- both Steve Bellovin and I presented the issues with such techniques. Basic challenge response mechanisms like CRAM-MD5 are simply too weak to be used on the Internet. They are subject to dictionary attacks, which can retrieve the password in a very short time. They don't deserve much more than documentation for historical purpose. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2195 (Was: what happened to newtrk?)
-Original Message- From: Frank Ellermann [mailto:[EMAIL PROTECTED] Sent: Thursday, September 07, 2006 7:49 PM To: ietf@ietf.org Subject: Re: RFC 2195 (Was: what happened to newtrk?) Christian Huitema wrote: both Steve Bellovin and I presented the issues with such techniques. Is that presentation online available somewhere ? I find the way to http://www3.ietf.org/proceedings/05aug/index.html but then I'm lost. http://www.huitema.net/talks/ietf63-security.ppt For a password in the dictionary, and if somebody sees the challenge and the response. With a somewhat unusual password I wouldn't know how an attack works. You would not, but the gentle folks writing the cracking tool certainly know. From the slide deck: - If (the password) is generated by the user, it can certainly be cracked - If (the password) can be remembered by the user, it can probably be cracked Basically, host should only accept password challenges on secure channels after properly identifying the server posing the challenge. CRAM-5 fails both tests. The channel is not encrypted, and the server can be easily spoof, e.g. in a rogue Wi-Fi hot spot. Note that this is not related to potential weaknesses in MD5. The dictionary attack works just fine with other hash functions. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Best practice for data encoding?
ASN.1 implementation bugs have also caused security problems for SSL, Kerberos, ISAKMP, and probably others. These bugs are also not due to shared code history: they turn up again and again. Are there any other binary protocols that can be usefully compared with ASN.1's security history? There is indeed a lot of complexity in ASN.1. At the root, ASN.1 is a basic T-L-V encoding format, similar to what we see in multiple IETF protocols. However, for various reasons, ASN.1 includes a number of encoding choices that are as many occasions for programming errors: * In most TLV applications, the type field is a simple number varying from 0 to 254, with the number 255 reserved for extension. In ASN.1, the type field is structured as a combination of scope and number, and the number itself can be encoded on a variable number of bytes. * In most TLV applications, the length field is a simple number. In ASN.1, the length field is variable length. * In most TLV applications, structures are delineated by the length field. In ASN.1, structures can be delineated either by the length field or by an end of structure mark. * In most TLV applications, a string is encoded as just a string of bytes. In ASN.1, it can be encoded either that way, or as a sequence of chunks, which conceivably could themselves be encoded as chunks. * Most applications tolerate some variations in component ordering and deal with optional components, but ASN.1 pushes that to an art form. * I don't remember exactly how many alphabet sets ASN.1 does support, but it is way more than your average application. * Most applications encode integer values by reference to classic computer encodings, e.g. signed/unsigned char, short, long, long-long. ASN.1 introduces its own encoding, which is variable length. * One can argue that SNMP makes a creative use of the Object Identifier data type of ASN.1, but one also has to wonder why this data type is specified in the language in the first place. Then there are MACRO definitions, VALUE specifications, and an even more complex definition of extension capabilities. In short, ASN.1 is vastly more complex that the average TLV encoding. The higher rate of errors is thus not entirely surprising. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
portability could be one outcome. Given that the point of this PI exercise seems to be to increase the viability of IPv6, maybe you should go for it, and add number portability too? That should further increase the viability. The IETF is an engineering organization. Engineers are good at engineering, not so good at setting policy. Let's assume that the policy is driven externally, and that engineers cannot impose their preferred solution. Some will say that the sky has begun to fall, and retire in an ivory tower of gloom. The optimistic engineer, on the other hand, will take that as a challenge. Clearly, the current set-up based on BGP and default-free tables is not set to absorb more than a small number of PI prefixes -- maybe a few thousands, maybe a few tens of thousands, certainly not a few hundred of millions. But who says that we cannot change it? Number portability, after all, only requires a layer of indirection. We can certainly engineer that! -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Dampening is part of the protocol and has nothing to do with the speed of light. Well, not really. Assume a simplistic model of the Internet with M core routers (in the default free zone) and N leaf AS, i.e. networks that have their own non-aggregated prefix. Now, assume that each of the leaf AS has a routing event with a basic frequency, F. Without dampening, each core router would see each of these events with that same frequency, F. Each router would thus see O(N*F) events per second. Since events imply some overhead in processing, message passing, etc, one can assume that at any given point in time there is a limit to what a router can swallow. In either N or F is too large, the router is cooked. Hence dampening at a rate D, so that N*F/D remains lower than the acceptable limit. Bottom line, you can only increase the number of routes if you are ready to dampen more aggressively. There is an obvious tragedy of the commons here: if more network want to multi-home and be declared in the core, then more aggressive dampening will be required, and each of the multi-homed networks will suffer from less precise routing, longer time to correct outages, etc. There are different elements at play that also limit the number of core routers. Basically, an event in a core router affects all the path that go through it, which depending on the structure of the graph is somewhere between O(M*log(M)) or O(M.log(M)). In short, the routing load grows much faster than linearly with the number of core routers. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Guidance needed on well known ports
1. Are well known ports archaic? If so, can we request that the IANA do away with the distinction? I don't know whether I would use the word archaic, but the distinction between 1024 and = 1024 is certainly Unix-specific. In the Windows operating systems, the port range 1-1023 is not special. Some Windows OS services use low port numbers, but not all. UPNP, for example, uses ports 1900 and 2500; the RPC applications use dynamic port numbers. 2. If they are not archaic, under what circumstances should they be allocated? I have no problem with the current system. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Guidance needed on well known ports
A more interesting question is this: what are the odds that a user process will accidentally grab the port number before the system process gets to it? The notion of a privileged port number is certainly preposterous; that said, putting services in a range that ordinary applications tend not to use has its merits. There are two issues there, accidental collision between a dynamic port and a service port, and voluntary collision between applications trying to open the same port. The practical solution to the first problem are to start services and grab ports as part of the boot sequence, i.e. before user processes start, and start dynamic allocations at some high number (e.g. larger than 1024 or larger than 4096 or some admin defined value depending on system version and configuration). If there is a reserved range, then it is easy to start dynamic allocation outside the range. Starting services quickly also helps with the voluntary collisions between system services and applications, but is not foolproof. In any case, it does not help with collisions between applications, e.g. two applications trying to use the same port. What does help there is an easily accessible registration system, so application developers can easily do the right thing, i.e. reserve a port and avoid collisions. Note the emphasis on easily accessible: if there are too many hoops to jump through, the developers will likely just pick a number at random. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
Hence the desire to have the RFC Editor use xml2rfc, rather than nroff. I don't think publishing the xml2rfc test is such a good idea. Xml2rfc is a preparation format. The printed result is a combination of the xml2rfc input and a formatting program of some kind. This formatting program is bound to change over time, e.g. when templates change. You want to archive the final result, not the initial input. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
XML2RFC submission would be based on an IETF standard, and I understand that many will find that attractive. However, for me, this is problematic. An interesting part of the current text format is that it is defined in a very simple way: so many lines, so many columns, that's about it. Compare that to an XML grammar: we define lines and lines of rules, attributes, sub attributes, and their expected meaning. Guess what: we are engineers, and engineers like to tinker. Given that tinkering with XML grammars is both very easy and very tempting, we can be pretty sure that there will be many revisions. An XML format is going to be much less stable than the current status! As a preparation tool, XML2RFC is probably OK. But it cannot be as stable and future proof as ASCII text as a final product format. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Please make sure that you do not run your WLAN in ad hoc mode
I think we should be very strict on this. All this people should get filtered until they go to the NOC and make sure to get trained about how to avoid ad-hoc ! Unlicensed spectrum, like the 2.4GHz and 5GHz bands used by Wi-Fi, can be used by anybody. If I remember correctly, there was an FCC ruling on a similar case, where an airport wanted to get airlines to stop using their own Wi-Fi devices, uncoordinated with the airport. The FCC essentially ruled that as it is an open band, landlords and other facility managers can't prevent people from using the waveband. I did not check the laws of Canada, but in the US at least the IETF cannot force people to stop using ad hoc. If two participants want to set up an ad hoc network and exchange data between themselves, there is hardly anything the NOC can say. They could also use Bluetooth, which operates in the same band, and again they would not be breaking any regulation. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard
My greatest concern is that the document as it stands is likely to cause a large number of bogus DNS queries. If the protocol is widely adopted, it seems probable that many clients will have LLMNR enabled on an interface in a situation where a DNS server has been configured (as described in section 2). In that case, every LLMNR query will entail (possibly more than) one DNS query, because of the provision, All attempts to resolve the name via DNS on all interfaces have failed after exhausting the searchlist. Such DNS queries will become commonplace if the protocol is widely adopted and widely used. This feature of the design appears to increase the burden on the entire Internet infrastructure in order to support unshared infrastructure. Uh, no. LLMNR does not create additional DNS queries. Applications do not issue LLMNR requests, they issue name resolution requests. When a name resolution request is issued, the current behavior is to submit the request to the DNS, possibly applying a search list. LLMNR does not change that. LLMNR adds an additional transaction at the end of the search list, falling back to local multicast resolution if the infrastructure could not resolve the query authoritatively. The part about multiple interfaces is also the current behavior in multi-homed hosts. In theory, DNS requests sent to different servers over different interfaces should all be equivalent. In practice, they are not. Some names can be resolved through some interfaces, and not through others. To be sure, systems end up sending the requests on multiple interfaces. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
From the data gathered by our root-server operators at that moment we estimate that the traffic for .local must have been some 25% A key technical difference between LLMNR and the initial MDNS proposal is precisely that LLMNR has no concept of a .local top level domain. Usage of LLMNR does not promote queries to this zone. This is indeed a key difference between LLMNR and MDNS. MDNS assumes that there is a special zone for local names, which would be linked to the topology. LLMNR assumes that names are independent of the topology, that a host called foo.example.net retains the same name as it move to different locations. There were ample debates of this point in the working group, and the decisions to not creating special names and not linking names to topology do reflect WG consensus. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Windows 98, Windows 2000 and Windows XP do not enable LLMNR by default. Christian, could you please tell us, for each OS mentioned, how to enable LLMNR? That would enable everyone participating in this discussion to witness for themselves exactly how it works and what it does. You would have to get an experimental implementation of LLMNR from some developer site. To the best of my knowledge, Microsoft is not shipping this code. In these systems, ad hoc names are resolved through NETBIOS. The .local queries observed in Peter's root servers is most certainly not caused by an LLMNR implementation. In the absence of LLMNR, if an application tries to resolve host.local through, say, gethostbyname, then the query will indeed be forwarded to the local DNS service. The responsibility for the .local traffic lies mostly into whoever is promoting use of this top level domain and coding that use in applications. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
I'm afraid I don't understand. As far as I can understand, mDNS uses the .local pseudo-domain and LLMNR does not. So how can LLMNR be blamed for bogus queries for *.local? I cannot garantie it was LLMNR. I was told these are windows boxes using the default enabled LLMNR and it defaults to .local. I know that newer windows boxes do have LLMNR but it is not normally used. Nevertheless it comes up. Windows 98, Windows 2000 and Windows XP do not enable LLMNR by default. Name resolution in these systems is performed through DNS or NetBIOS/WINS. Hosts using these systems are not expected to be aware of a complete list of top-level domains. Queries for unknown domains will indeed be routed by default to the local DNS servers. One could argue that special knowledge for some reserved names (.local or .example) should be wired in every host. But it is simpler to program this knowledge in the local name servers, thus avoiding undue traffic to the root servers without risking interop issues and name conficts in local naming plans. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: what is a threat analysis?
The reason I brought this to this list is because there's no clarity about what is meant by a threat analysis, though it seems to be cropping up more and more in the IETF process (look ma! no hoops!). If it's going to be part of our process, then I think its incumbent on those who want to impose the process to be clear about what they're asking for, and for that process to not be an idiosyncratic. The waste of time here is not the process per se, but the work on drafts, etc, that are not what the person making the demand is asking for. Do you have an objection to clarity in process? I personally consider threat analysis an integral part of protocol design. A well written security consideration should read very much as a threat analysis: what are the system's assets that need protection; what are the possible interfaces through which attacks can be conducted; enumerate the likely attacks through those interfaces; ensure that all these attacks are properly mitigated. Doing that at design time is much easier than trying to retrofit security when attacks are found in the wild. As Eric Fleischman pointed out, doing good security analyses requires training. In particular, the enumeration of possible attacks looks very much like a brainstorming session, and relies on the expertise of working group members. However, members of an engineering organization like the IETF ought to be eager to acquire such training. I mean, do you really want to design insecure protocols? For those interested in self training, I recommend the book Writing Secure Code, Second Edition by Michael Howard and David LeBlanc (http://www.microsoft.com/mspress/books/5957.asp). -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 2434 term IESG approval (Re: IANA Action: Assignment ofan IPV6 Hop-by-hop Option)
I think as has already been suggested we are having two different discussions masquerade as one. I obviously can't speak for Robert but it seems to me he is not saying the IESG ought to approve every (or any) extension of IP, he is merely saying each should have an option number assigned. Why assign a dangerous, harmful protocol an option? For the same reason sex offenders in the US have to register - so everyone can be aware of their presence and take the appropriate precautions. The problem is the really small size of the option type field in IPv6. There really only are 5 bits available for numbering both the hop by hop and the end to end options. That makes for a grand total of 32, of which three are assigned by basic IPv6 specs. So, there really are good reasons to be somewhat conservative with the assignments. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Email Submission Between Independent Networks' to BCP
(1) known weaknesses [citations] is significantly different from we don't like it or we assert it is bad or even we don't like things unless they contain several additional layers. The third of these might be a reasonable statement, but would require even more justification because... Times change. Today, using challenge response mechanisms such as CRAM-MD5 over un-encrypted channels is not much more secure than sending password in clear text. If a third party can listen to the challenge and response, and then mount a dictionary attack. Steve Bellovin was alluding to the evil twin attack on wireless network. Allow me to elaborate. The technique allows an attacker to lure unsuspecting travelers to connect to an un-protected wireless network under the attacker control. Very often, laptops are programmed to fetch pending e-mail as soon as they connect to a network. The laptop will try resolve mail.example.com, and start a POP3 or IMAP exchange. The attacker controls the DNS service on the wireless network, and will easily spoof the server. It will then respond to the connection with a CRAM-MD5 challenge, and harvest the e-mail address of the victim as well as the answer to the challenge. The attacker is now in a position to obtain the e-mail and password pair for the victim. The attack lasts a few seconds, and may not require any particular action by the victim. IETF protocols should not endorse the use of unprotected challenge-response mechanism. They certainly should not lure clients to accept challenges from unauthenticated servers. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Uneccesary slowness.
Friday, May 20, at 2005 8:54 AM Sean Dorman wrote: The purpose of IETF is to provide documented standards and guidelines that help guide the market, NOT the other way around. There is no agreement that this is in fact the purpose of the IETF. Historically, the IETF has engaged in two types of activities, creating technology that was perceived as much needed for the Internet, and driving consensus between implementers on specific functions. The implementers' consensus working groups are typically market driven. A bunch of companies or non-profit groups realize that they are working on quasi similar products, and that using an interoperable standard would be more efficient than letting the market sort out between proprietary designs. Such working groups typically have strong timing requirements. If the IETF takes too long to reach consensus, then proprietary solutions will gain market share, and the late coming IETF specification will be essentially irrelevant. Having delays because the working group cannot agree is bas enough, but it can usually be avoided by just letting several proposals progress in parallel -- a choice between two standard ways being sometimes perceived as more efficient than complete fragmentation. On the other hand, there is no excuse for delays created by bureaucratic processes and arbitrary pocket vetoes. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Complaining about ADs to Nomcom (Re: Voting (again))
Margaret Wasserman wrote: What is reasonable turnover for the IESG? ... successful ADs who are willing to continue serving will probably be in-office for an average of 8-10 years (4-5 terms). This seems to match existing practice. I personally find that this is too long. What level of turnover do you think would be healthy? And what would be the impacts of having more new ADs each year? My personal preference would be an average of 4 to 6 years. You have to ensure turnover for multiple reasons: even if you have the best intentions, power does corrupt, attention fades, you get disconnected from your peers, you develop an us versus them attitude, etc. I don't necessarily believe in term limits, but remaining in an AD position for more than 8 years feels very unhealthy. This is a volunteer organization. When you get a management position, your attitude should to make the best possible job for the duration of your mandate, then voluntarily withdraw and let someone take the next watch. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Complaining about ADs to Nomcom (Re: Voting (again))
Do you actually think that we need an even higher turnover? Or are you pointing out an historical problem which may have been corrected over the past two years? I was merely reacting to your assessment that renewal rate by the nom com of less than 25% leads to average terms of 8-10 years, which in my mind is too long. As you point out, in practice, people tend to not stay much longer than 4 years -- and we should thank them for serving even that long. There were a few examples of AD serving for 10 years or more, it is not the case anymore, and that is very well. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: french crypto regulations relating to personal encryption usage by visitors?
And as an American, I'd just like to say that this is an embarrassment to me. Free trade, but not free travel. How can you have one without the other? Actually, there was a period in the 80's during which US tourists had to obtain a visa before visiting France. This followed terrorist bombings in Paris. The French authorities wanted to restrict movements of potential terrorists. The terrorist movements involved nationals of former French colonies, and given various treaties it was only possible to require visas for nationals of these countries if they were also required from nationals of every country outside the European Union -- including the US. Do you see the parallel with the current US legislation? -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: MARID back from the grave?
Thanks. I forgot to say on (c) that there MUST be as many entries in the revision history as the revision number indicates (i.e. none for revision 00, and so on). don't do that. it will add an unnecessary and often useless barrier to publication of I-Ds I-Ds are supposed to be a quick-and-dirty mechanism for circulating (sometimes quite rough) drafts among interested parties. we don't need to impose a complicated revision history mechanism just because we have two different cutoff dates for I-Ds. and there's certainly no need to impose such a requirement on drafts that (a) aren't WG work items and (b) are submitted before the earlier cutoff date. In fact, we only have two points of contentions: old personal drafts submitted as version 00 of WG drafts; and old WG drafts submitted as version 00 of new personal drafts. The first scenario is easily taken care off by granting an exemption for the cut off date. The secretariat is already supposed to ask WG chair approval for WG drafts, and WG drafts almost never are first drafts; we could easily tell the secretariat that WG drafts are subject to the same deadline as version N+1 drafts. The second scenario requires being a little bit more proactive. Keeping the version number while changing the prefix is probably a good idea. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: MARID back from the grave?
What is particularly ironic is that these I-Ds began as individual submissions and we were asked to bring them in, under Marid, just in time for the working group to be disbanded. We have seen that situation before, for example when the NGTRANS working group was disbanded. Some of the work was picked up by a new working group, but to start with a clean base all drafts had to be resubmitted as individual contribution. At this point, we get the deadline effect: a work that in reality is a revision has now to meet the original submission deadline. That's not very fair. In these conditions, there should be some kind of automatic exemption, maybe by allowing drafts to use an N+1 version number. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-phillips-langtags-08, process, specifications, and extensions
Could you please pursue this rather technical discussion on a specialized list, rather than the main IETF list? -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
