Re: Comments on draft-ietf-bmwg-hash-stuffing-05.txt
I have reviewed this document. My comments are interspersed with Joe's. Salowey, Joe wrote: I reviewed this document ( Hash and Stuffing: Overlooked Factors in Network Device Benchmarking ) as part of a cross area security review. In general I think the document looks OK. I have a few comments: 1. It might be nice if the document stated something along the following in the security considerations section: Injecting random traffic into a network can result in disruption of service and the raising of security and fault alarms. These tests must not be performed on a network without prior approval from the network owners and operators. These tests should not be performed on a production network. This may seem like common sense, but stuff happens. The draft currently contains the sentence: This attack could consume up to 100 percent of available bandwidth. However, the test networks described in BMWG documents generally SHOULD NOT be reachable by anyone other than the tester(s). which seems to imply that except in extra ordinary cases the networks used for BMWG testing SHOULD be private. I had the same reaction as Joe that it should be explicitly indicated that public networks SHOULD NOT be used unless all the affected parties have either given approval or been notified. 2. Use of pseudorandom number generators The behavior of pseudo random generators is implementation specific, they are not all created equal. PRNGs may have biases that make them unsuitable for security applications or numerical simulations. I have not done a detailed analysis of the application to testing, but in general I think testing applications are less sensitive. If enough test data is consumed then non-ideal behavior make cause artificial patterns in the test result data. Some low quality PRNG's may also exhibit biases. RFC 4806 describes ways to deal with some of these problems for security applications. The recommendations here would be sufficient for testing applications, although they would probably overkill. One thing to be aware of with PRNG implementations is that they depend upon a seed. For the same seed (initial state) they give the same output. Different implementations may treat seeds and internal state management differently. Making subsequent calls to the same PRF with the same seed will often result in the same sequence. This could result in a less than uniform distribution depending on how the seeding is done. Maybe the document should state something along the following lines: This document recommends the use of pseudorandom patterns in test traffic. This usage requires a uniform distribution, but does not have strict predictability requirements. The recommendations in RFC 4806 are for security applications and would produce output that is more than sufficient for testing applications. Although it is not sufficient for security applications, the rand() function of many programming languages may provide a uniform distribution that is usable for testing purposes. Implementations of rand() may vary and provide different properties so test designers should understand the distribution created by the underlying function and how seeding the initial state affects its behavior. I don't think this text belongs in the security section, if it does then it should recommend following RFC 4806. Section 3.1 of the draft indicates that Repeatability is a desired goal of the benchmarking. As such use of rand() with a fixed seed would appear to be an appropriate source of input data provided that the output sequence did in fact provide for a uniform distribution of values. Section 3.2 of the draft describes the Randomness requirements of benchmarking. This document recommends the use of pseudorandom patterns in test traffic under controlled lab conditions. The rand() functions available in many programming languages produce output that is pseudorandom rather than truly random. Pseudorandom patterns are sufficient for the recommendations given in this document, provided they produce output that is uniformly distributed across the pattern space. Specifically, for any random bit pattern of length L, the probability of generating that specific pattern SHOULD equal 1 over 2 to the Lth power. I do not believe the use of randomness in this draft is a security consideration. The question I am left with is, is repeatability more or less important than randomness? If randomness is more important than I believe a variation on Joe's text is appropriate. If repeatability is more important, then I believe a stronger recommendation of rand() and specified seed values would be appropriate. 3. (More of a note to the IETF and IESG) This document highlights some areas which are general security issues. For example the document does mention stuffing vulnerabilities. These are discussed in some protocol documents,
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
v | /\ +-+ / \ ++ | Upgrade |__/ ? \__| Give money | | To IPv6 | \/ | to Michel | +-+ \ / ++ \/ M. Tough call. Yes, it is. It's called long term strategic investment versus short term profit taking. That's a very tough call. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
Brian, Michel Py wrote: v | /\ +-+ / \ ++ | Upgrade |__/ ? \__| Give money | | To IPv6 | \/ | to Michel | +-+ \ / ++ \/ M. Tough call. Brian E Carpenter wrote: Yes, it is. It's called long term strategic investment versus short term profit taking. That's a very tough call. If Boeing had rolled out IPv6 in 1993-1994 when Eric wrote RFC1687 it would not have done anything to their bottom line as of today and wasted my money. If they had deployed 5 years ago there still would be no return as of today and if they deployed today I see no return (in reduced operating costs) for 5 years. As a shareholder my best interest so far has been not to deploy. My instructions are: keep an eye on the situation, if there is a change in conditions that means IPv6 buck could bring bang _then_ go for it; in the mean time put my cash where it does bring some bang, either by developing new products or by paying me dividends 4 times a year. As long as other shareholders (especially the ones who work there and likely have scores of unvested shares) think the same way, this is the deal. Eliot Lear wrote: Boeing has enough devices and networks that it could on its own probably exhaust a substantial portion of remaining IPv4 address space we have now. They certainly have more than a /8's worth, and that poses RFC1918 problems Boeing has 159,000 employees. RFC1918 space is 17,891,328 addresses. That's more than 100 IP addresses per employee, I think Eric can manage. That being said, I do acknowledge that larger companies such as global ISPs do have a problem with the RFC1918 space being too small. This brings the debate of what to do with class E, either make it extended private space or make it global unicast. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
If Boeing had rolled out IPv6 in 1993-1994 when Eric wrote RFC1687 it would not have done anything to their bottom line as of today and wasted my money. If Boeing had rolled out IPv6 in 1993-1994 by now they would have an efficient production and real time inventory management; would have saved billions in costs and were giving (at least part of it) to Michel. As a shareholder you may want to think how you vote during the next shareholders meeting. Cheers, [EMAIL PROTECTED] --- Michel Py [EMAIL PROTECTED] wrote: Brian, Michel Py wrote: v | /\ +-+ / \ ++ | Upgrade |__/ ? \__| Give money | | To IPv6 | \/ | to Michel | +-+ \ / ++ \/ M. Tough call. Brian E Carpenter wrote: Yes, it is. It's called long term strategic investment versus short term profit taking. That's a very tough call. If Boeing had rolled out IPv6 in 1993-1994 when Eric wrote RFC1687 it would not have done anything to their bottom line as of today and wasted my money. If they had deployed 5 years ago there still would be no return as of today and if they deployed today I see no return (in reduced operating costs) for 5 years. As a shareholder my best interest so far has been not to deploy. My instructions are: keep an eye on the situation, if there is a change in conditions that means IPv6 buck could bring bang _then_ go for it; in the mean time put my cash where it does bring some bang, either by developing new products or by paying me dividends 4 times a year. As long as other shareholders (especially the ones who work there and likely have scores of unvested shares) think the same way, this is the deal. Eliot Lear wrote: Boeing has enough devices and networks that it could on its own probably exhaust a substantial portion of remaining IPv4 address space we have now. They certainly have more than a /8's worth, and that poses RFC1918 problems Boeing has 159,000 employees. RFC1918 space is 17,891,328 addresses. That's more than 100 IP addresses per employee, I think Eric can manage. That being said, I do acknowledge that larger companies such as global ISPs do have a problem with the RFC1918 space being too small. This brings the debate of what to do with class E, either make it extended private space or make it global unicast. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
From: [EMAIL PROTECTED] [EMAIL PROTECTED] If Boeing had rolled out IPv6 in 1993-1994 by now they would have ... real time inventory management Wow! I've heard all sorts of claims for what IPv6 will do/include, but I must say that's a new one Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor and 2006 timeline
Leslie, IAB, and others, Three observations on the schedule (included below for convenience), based on the events of the last month... (1) The initial STRAW PROPOSAL draft of the new RFC Editor charter, in your email of 16 March, says, in part,... The purpose of this straw proposal is to inform discussions scheduled for the GENAREA meeting at IETF65 in Dallas. After the Dallas meeting, the IAB will provide a more formal charter proposal. I, and I assume others, had assumed that this meant that, after the Dallas discussion, the IAB would post an Internet-Draft with the expected more formal text so as to permit community comment before the presumably-final version was posted, not later than Saturday. I do not believe that has occurred, so what is the plan for posting of a Revised Charter for comment? (2) As your 16 March posting noted, moving forward with an actual RFP process -- presumably starting with whatever requirements are stated in the request for expressions of interest to be issued on May 7 -- requires that there be documents analogous to the TechSpec one for non-IETF documents. With the assistance of a few colleagues, I have put together and submitted draft-klensin-rfc-independent-00.txt, which is a first cut at the independent submission model. I assume it will be posted today but, of course, there has not yet been any opportunity for community discussion on it. How would you like to proceed on that front? (3) While I didn't realize it last month, there are at least a few tasks traditionally associated with the RFC Editor function that do not seem to be covered by the outline and schedule below at all. For example, we still have 50-odd older RFCs that are not online. As far as I know, few, if any, of the IENs are online and readily accessible either. I don't know that getting these online is necessarily an appropriate RFC Editor (or RFC-Editor-bis) activity, although it has been considered to fall within that scope in the past. But those documents are important enough historically --occasionally even to the work of the IETF-- that they should all be online and accessible... and making that happen should be someone's responsibility.There may be other areas like this; we should somehow be sure that they are all covered somehow. Because of things like this, I'm sort of hoping that the IASA will decide to issue an RFI, not merely a call for expressions of interest, so as to get as much information on these subjects and understanding of roles from potential vendors as possible. regards, john --On Thursday, 16 March, 2006 18:04 -0500 Leslie Daigle [EMAIL PROTECTED] wrote: The IAB and IAOC have put together the following proposed plan for clarifying the RFC Editor function and running through a contract review process this year. The key pieces of this proposed process are: . getting agreement on a basic RFC Editor charter . completing TechSpec to describe requirements for IETF technical specification publication . developing analogous components for independent submissions, IRTF documents, etc. (Not all yet on the timeline). Comments welcome. Draft timeline/division of labour = Responsible parties in [], where IASA is IAD or IAOC as appropriate. Mar 14 2006 [IAB] Draft RFC Editor charter out for public comment. Mar 20 2006 [TechSpec/IETF] TechSpec meeting Mar 20 2006 [IAB/IETF] Discuss RFC Editor charter Apr 15 2006 [TechSpec] Target reasonable consensus document. Apr 15 2006 [IETF] Start of 4 week last call of TechSpec document Apr 15 2006 [IAB] Revised RFC Editor charter. May 7 2006[IASA] Request for Vendor Expressions of Interest May 15 2006 Close of last call of TechSpec document Jun 1 2006[IASA] Vendor Expressions of Interest Due Jul 15 2006[IASA] RFP(s) Issued Sep 1 2006[IASA] Bids Due Sep 2006[IASA] Contract Negotiation Sep 25 2006[IAB] IAB review Oct 1 2006[IASA] Contract(s) Awarded Oct – Dec[IASA] Transition Period Jan 1 2007 Contract term begins Leslie Daigle. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
