Re: [Full-disclosure] IPv6 security myths
Hadriel Kaplan wrote: >> Do you know some major application over the Internet using IPsec >> with transport mode? > > Yes: SIP. SIP/UDP over IPsec in transport mode on the Internet > is not uncommon. Arguably more common than SIP over TLS, > anyway... though that's expected to change. (and of course SIP > over IPsec or TLS are both noise compared with plain SIP over UDP) Yes, IPv6 deployment also is expected to change. > Also, Femtocells running various protocols typically use IPsec > over the Internet, though in tunnel mode I believe - but one > wouldn't think of it as being a "VPN" in the traditional sense. It's a traditional VPN to encrypt data to/from mobile terminals in femtocells by femtocell stations. In the same VPN, protocols to control the stations may also be carried, which does not make the VPN not traditional. > Oh, and I believe storage/SAN (FCIP, iFCP, iSCSI) use IPsec over > the Internet; or at least the IPsec chip vendors seem to focus > on those markets a lot. Though again in tunnel mode I think, > but not a classic "VPN" use. Are you saying the SAN is a part of the public Internet? > The Internet is big and diverse - not everything is HTTP and DNS. ;) So? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More labels for RFCs
On 31.10.2010 16:51, Hadriel Kaplan wrote: On Oct 31, 2010, at 5:27 AM, Julian Reschke wrote: All RFCs published since last January have that pointer in the boilerplate, it goes to http://www.rfc-editor.org/info/rfc Sweet. :) I actually checked the boilerplate I use for I-D's before saying it, but I guess my boilerplate is old. Oh, it's only in RFCs... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
On Oct 31, 2010, at 12:00 AM, Masataka Ohta wrote: > TJ wrote: >> I would be quite curious to know your definition of failure, given that >> IPsec is currently deployed, and working in "more than a few" deployments >> ... > > Sorry for lack of clarification. > My context is IPsec in the Internet, which excludes VPNs. That's a strange exclusion, considering VPNs have been the primary use-case for IPsec over the Internet. > Do you know some major application over the Internet using IPsec > with transport mode? Yes: SIP. SIP/UDP over IPsec in transport mode on the Internet is not uncommon. Arguably more common than SIP over TLS, anyway... though that's expected to change. (and of course SIP over IPsec or TLS are both noise compared with plain SIP over UDP) Also, Femtocells running various protocols typically use IPsec over the Internet, though in tunnel mode I believe - but one wouldn't think of it as being a "VPN" in the traditional sense. Oh, and I believe storage/SAN (FCIP, iFCP, iSCSI) use IPsec over the Internet; or at least the IPsec chip vendors seem to focus on those markets a lot. Though again in tunnel mode I think, but not a classic "VPN" use. The Internet is big and diverse - not everything is HTTP and DNS. ;) -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More labels for RFCs
On Oct 31, 2010, at 5:27 AM, Julian Reschke wrote: > > All RFCs published since last January have that pointer in the > boilerplate, it goes to > > http://www.rfc-editor.org/info/rfc Sweet. :) I actually checked the boilerplate I use for I-D's before saying it, but I guess my boilerplate is old. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternate entry document model
On 10/30/2010 11:31 AM, Joel M. Halpern wrote: One of the positive effects of our current system is taht because WG knows tha tthye have to clear all the ADs, not just their own, they actually think about all these issues. And usually manage to cope with them A working group is diligent or it isn't. It gets a range of feedback and responds constructively to it... or it doesn't. The working group behaviors that I have seen that pay explicit attention to the specific question of satisfying AD reviews have nothing to do with quality of the work and more to do with guessing what will personally bother an AD. In other words, it's about dealing with AD idiosyncrasy rather than with quality. It is now common to get cross-area reviews and my own observation is that these are a) typically quite reasonable and diligent, and b) dealt with constructive by the working group. ADs do sometimes come up with interesting and even important points, but AD review is an extremely expensive and often frustrating mechanism that we already have a vastly superior replacement for. Its timing is better and it distributes the work far better. The fact that an AD sometimes catches some important problem is typically taken as proof that the AD review and Discuss mechanism is essential. This is highly flawed logic, on two counts. One is that it does not represent meaningful cost/benefit evaluation. The cost is actually quite high in energy, delay and frustration, and the significant benefit overall is quite low (if the wg has been diligent and has gotten cross-area reviews.) The other is that protocol specs have a statistical likelihood of bugs, even with the AD review. We talk about AD review almost as if it ensures perfection, but of course we know it does not. Ultimately, we have to trust the real world to evaluate the safety and efficacy of a protocol. That fact ought to give us permission to balance the cost and benefit of the quality assurance efforts we require during specification development and approval. Yes, it would be very good to spot all of these things sooner. I have not yet seen a proposal that actually works for doing so. But letting WGs or WGs + ADs approve documents for general advancement is a step likely to lead to problems. If all our WGs handed their ADs high quality documents that they had checked for all these issues, then maybe we could look at this differently. We do need quality assurance efforts. The basic idea that working group efforts are subject to outside review prior to approval is a significant value-add by the IETF, IMO. The question is how to provide sufficient review in a reasonable way. I believe that cross-area reviews largely satisfy that requirement. If within-area reviews are also needed, the AD should commission them, not do them directly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
If you mean widespread, point to point / peer to peer IPsec - yes, there is a distinct lack of (free, easy, global) PKI out there. There are steps in the right direction though, such as MS's Direct Access ... /TJ On Oct 31, 2010 12:02 AM, "Masataka Ohta" wrote: > TJ wrote: >> I would be quite curious to know your definition of failure, given that >> IPsec is currently deployed, and working in "more than a few" deployments >> ... > > Sorry for lack of clarification. > > My context is IPsec in the Internet, which excludes VPNs. > > Do you know some major application over the Internet using IPsec > with transport mode? > > Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RE: [Full-disclosure] IPv6 security myths
Perhaps I should have said deployable ... Although it is deployed in some places, and growing rapidly - I'd be surprised if your situation didn't change over then next 12-15 months ... /TJ On Oct 30, 2010 11:28 PM, "Michel Py" wrote: >> TJ [trej...@gmail.com] wrote: >> I would be quite curious to know your definition of failure, given > that >> IPsec is currently deployed, and working in "more than a few" > deployments >> On a possibly related note, IPv6 use deployed and working too ... > > Failure means that, I leave in the capital city of California and I > can't find a single ISP that offers native IPv6. We're in the end of > 2010. And no change in sight. Tunnels? Oh yes tunnels. I had that 10 > years ago. > > You call that deployed? > > Michel. > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More labels for RFCs
On 29.10.2010 18:20, Hadriel Kaplan wrote: ... The problem with a labeling scheme like this is it's subjective. "Updates" and "Obsoletes" are not subjective, and to determine whether to apply those two labels is fairly easy. Labels of the form *-Quality would cause massive debate and need a WG-wide or larger consensus agreement process, if you mean them to be formal labels. ... It's only sometimes easy. It get's really hard when the "old" RFC combines too many different things (like a new HTTP method, one application for it, and a registry because previously there was none), or when the new spec is actually a set of RFCs. For some of what you describe above, people already produce RFCs to document - RFCs which deprecate a previous RFC, or enumerate issues found, or BCPs, etc. And obviously errata are already captured by the RFC editor. What's missing I think is some way to remind/force readers of an RFC to check for errata and updating/obsoleting RFCs, and how. Since it's a static document when published, I think the most natural way would be to add to the boilerplate a sentence reminding the reader to check for updates, obsoletes, and errata at "http://datatracker.ietf.org/doc/rfc"; where is filled in by the RFC Editor upon RFC publication. All RFCs published since last January have that pointer in the boilerplate, it goes to http://www.rfc-editor.org/info/rfc (now if we published specs in (X)HTML, people might actually click on it) Or if you want to be really fancy, you could have the IETF auto-create a Wiki type page for each RFC, that allows open community wiki-input about quality and implementation/deployment experience and such, with a big banner indicating the wiki content is not an official IETF position. That might be a good thing to have. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
Francis Dupont wrote: > In your previous mail you wrote: > > My context is IPsec in the Internet, which excludes VPNs. > > => this is a bit unfair: VPNs are the natural model for IPsec use > (putting back an uniform I could talk about red and black :-). It's fair as we are talking about IPsec as IPv6 security myth. It is of course that IPsec tunnel mode is used by IPv4 and/or IPv6 VPN gateways. But it does not make IPv6 more secure than IPv4. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
In your previous mail you wrote: My context is IPsec in the Internet, which excludes VPNs. => this is a bit unfair: VPNs are the natural model for IPsec use (putting back an uniform I could talk about red and black :-). Do you know some major application over the Internet using IPsec with transport mode? Regards francis.dup...@fdupont.fr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
