Re: [ietf] DNS spoofing at captive portals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi John, On 09/26/2010 04:34 AM, John R. Levine wrote: But we have real situtations where the opposite is true, quite possibly more often than the other way around. Not really. There turn out to be a significant number of domains, in the hundreds of thousands at least, that are purely evil. Some host So, if DNSSEC is enabled with an end-host validator and the ISP cache returns a different record for such a domain, the DNSSEC validator will mark it as bogus and the user gets a serverfailure response. The domain cannot be accessed. This is exactly right. DNSSEC provides integrity checks, it does not synthesize the original data out of thin air. Thus, domains can be blocked. As I said in a previous message, I am not a big fan of rewriting NXDOMAIN, and I was on one of ICANN's advisory committees and helped Showing an advert then, does not work. Of course, showing an advert on someone elses domain name is not particularly nice. So, an ISP can provide a DNSSEC-enabled cache (that can validate as well), and can block malware, and end-users can use that cache, and run their own validator to secure the path to the ISP cache. So, an end-user can run a validator that is still a 'stub' that connects to the ISP cache. This is much more efficient too as the ISP cache has all the data (and DNSSEC signatures) in its cache. A remaining stumbling block (well, once the ISP runs a DNSSEC cache), is the cablemodem-thingy, but it turns out these can (very often) be circumvented by providing the validating-stub on the end-users machine with the direct IP-address(es) of the ISP cache. Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkygTQYACgkQkDLqNwOhpPgbdACfbCRxW3Rii+MlFOUVeCl+HVRM CJwAoLHbvFWyMSH+rf0wjuCcNR2jnz88 =JuT/ -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Posting Placement (was Re: Fisking vs Top-Posting)
In the context of a long thread about style and readability[*] Joel M. Halpern summarized: I do want to re-iterate two points I have seen that are important. Both are relevant no matter what style of posting you like. 1) People need to read the whole email before composing their response. (You can draft ideas while reading, but make sure you actually read the whole thing before you finalise your response.) 2) People need to edit longer threads so that they do not copy large amounts of redundant and useless text. I would think that there is a 3rd point: 3) Think about what you would want to communicate, who to communicate to, and what style fits best. Fisking, classical Oxbridge rhetoric, top-posting, satire, acronyms (WFM, or 1+), one-liners, essays, YELLING, not-replying-at-all, c, c all seem to have their own effectivity and charm. In that contest I observe that by looking at the From: header you can often predict the style that is used while in an ideal world you would like to see correlation with the Subject: header. --Olaf [*] See for the whole thread: https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=53746tid=1285574931 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF-meta (was: Fisking vs Top-Posting)
NEW NON-IETF LIST ANNOUNCEMENT IETF Meta-Discussions This group is dedicated to the discussion of ancillary issues of interest to the IETF community, especially discussions about how IETF discussions and meetings should work. -- IETF meeting locations / travel -- Email composition design patterns -- Anything related to DiffServ politics http://groups.google.com/group/ietf-meta On Sep 20, 2010, at 2:20 PM, Phillip Hallam-Baker wrote: One of the problems I have seen emerge on many IETF mailing lists is the habit of fisking. By fisking I mean responding to a post line by line *while reading it for the first time*. Now sometimes a line by line response is entirely appropriate. If someone raises six different issues, you want to respond to each one separately. But other times I see posts of the following form: We should buy the red van Are you crazy, the last three vans were yellow. Only an idiot would buy a red van (etc) Because even though yellow is traditional the red one is on sale for $1000 off. I seem to be reading an increasing number of posts on various lists where it is very clear to me that the poster did not bother to read the entire message before starting their reply. In particular I have read rather a lot of people starting off by accusing their opponent of being ignorant of issues that their opponent actually states only a few paragraphs further on. Traditionally, top-posting (or bottom posting) has been discouraged in favor of responding line by line. I think it is time to reverse that preference. In particular I find that arguments are often less combative and somewhat shorter in mediums where people are forced to restate the issue they are objecting to in their own words. -- Website: http://hallambaker.com/ ___ 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: [ietf] DNS spoofing at captive portals
The point raised by John Levine is amongst my concerns. And one of the reasons that I have been looking at a different approach to the use of DNSSEC information that does not change the DNS model as radically as the end to end DNSSEC model. The idea of using DNS resolver as a proxy is a good one in my view. The problem with that model comes from the broken idea that a mobile host should accept any DNS service offered via DHCP. A DNS resolver is a trusted service, a host should not take just any DNS resolver, it should choose a resolver and establish a secure connection to it that at a minimum provides authentication but should ideally provide confidentiality as well. This is the case irregardless of whether DNSSEC is deployed or not. A DNS resolver is a trusted intermediary even in the case that DNSSEC deployment at servers is ubiquitous and clients are capable of DNSSEC end-to-end. Once we have a model in which the DNS resolver relationship is trusted and the communication to that resolver is secured, it is possible to use the DNS resolver in much more interesting ways. An end host can no more make sense of DNSSEC information on its own than a single mail server can deal with spam effectively. A DNS resolver with substantial throughput can collect the state data necessary to apply DNS information intelligently. DNSSEC is a mechanism for establishing inter-domain trust. It is not an appropriate technology for intra-domain trust. I do not want to connect my machines to every domain in the ICANN DNS repository. And I certainly don't want ICANN to start restricting issue of domains to people I or anyone else approves. DNSSEC can tell my resolver what the authoritative DNS registry is. But that resolver will then edit that registry to remove the domains that do not meet my security criteria. On Fri, Sep 24, 2010 at 8:16 PM, John Levine jo...@iecc.com wrote: Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Something else occurs to me: Plan C: Sophisticated ISPs might configure their own DNSSEC key into customer resolvers, and sign replacement records with that. The threat model for DNSSEC has always been, approximately, that the authoritative server at the far end is friendly, and the middleboxes are hostile. But we have real situtations where the opposite is true, quite possibly more often than the other way around. If we want people deploying DNSSEC widely, we need to make sure it handles the actual threats they face. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
That is not the right question. The question should be, who chooses for me? My answer to the question does not have to be the same as other people's. Some people will want the full ICANN registry with every scammy malware site and every DNS name registered five minutes ago. Others will prefer to have only the ones proven safe. If I was running a power station in the US, I would probably be quite happy with a very short list indeed. Gen Alexander is proposing a separate network for critical infrastructure. I think that an edited DNS could play a very important role. On Fri, Sep 24, 2010 at 9:10 PM, bill manning bmann...@isi.edu wrote: On 24September2010Friday, at 17:16, John Levine wrote: Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Something else occurs to me: Plan C: Sophisticated ISPs might configure their own DNSSEC key into customer resolvers, and sign replacement records with that. The threat model for DNSSEC has always been, approximately, that the authoritative server at the far end is friendly, and the middleboxes are hostile. But we have real situtations where the opposite is true, quite possibly more often than the other way around. presuming your statement about an inversion of the stated trust model is correct, can we dereference friendly and hostile to whom? Who makes that assessment and who/what defines the tools to implement a trust policy? --bill If we want people deploying DNSSEC widely, we need to make sure it handles the actual threats they face. R's, John PS: If I plug my random Windows PC or Mac into a cable modem, and I tell it to use DNSSEC, where does it get the top level validation keys? ___ 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 -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
actually, it was the right questions... and the answers all distill down to your reply. security and trust are in the eyes/validator of the beholder. Sam Weiler borrowed the term local policy - which trumps any middleman. Steve B. suggests VPNs (or their functioal eqivalant) between the authoritative or trusted source and the end-system validator - where in this context, the validator/resolver is w/in a couple usec of the application; e.g. in the same box. you can do it yourself or you can outsource it to someone else. end of the day, its the end-system operators choice. the tools for crisply defining the constrainsts of local policy are still very crude/fuzzy/undefined. --bill On Fri, Sep 24, 2010 at 10:16:05PM -0400, Phillip Hallam-Baker wrote: That is not the right question. The question should be, who chooses for me? My answer to the question does not have to be the same as other people's. Some people will want the full ICANN registry with every scammy malware site and every DNS name registered five minutes ago. Others will prefer to have only the ones proven safe. If I was running a power station in the US, I would probably be quite happy with a very short list indeed. Gen Alexander is proposing a separate network for critical infrastructure. I think that an edited DNS could play a very important role. On Fri, Sep 24, 2010 at 9:10 PM, bill manning bmann...@isi.edu wrote: On 24September2010Friday, at 17:16, John Levine wrote: Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Something else occurs to me: Plan C: Sophisticated ISPs might configure their own DNSSEC key into customer resolvers, and sign replacement records with that. The threat model for DNSSEC has always been, approximately, that the authoritative server at the far end is friendly, and the middleboxes are hostile. But we have real situtations where the opposite is true, quite possibly more often than the other way around. presuming your statement about an inversion of the stated trust model is correct, can we dereference friendly and hostile to whom? Who makes that assessment and who/what defines the tools to implement a trust policy? --bill If we want people deploying DNSSEC widely, we need to make sure it handles the actual threats they face. R's, John PS: If I plug my random Windows PC or Mac into a cable modem, and I tell it to use DNSSEC, where does it get the top level validation keys? ___ 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 -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
I don't see why DNSSEC makes dropping out zones impossible. All DNSSEC does is to enable the end point to know that there is data missing. It does not provide the end zone with any way to find the missing data, nor is there any user interaction that makes any real sense in that situation. But the real answer to the problem is that the root zone signature is not the root of trust for my DNS, it is the root of trust for the ICANN DNS. myDNS = icannDNS - maliciousDNS I plan to publish my root cert for my zone at the apex of my DNS zone and establish that out-of-band as the trust anchor for every device and application in my network. Hosts in my network will determine that a secure DNS resolver is available for the zone via the ESRV mechanism I recently proposed and establish a secure tunnel with my DNS resolver via a protocol TBS, but probably based on either the TLS handshake to establish a ticket containing all necessary server-side state or the existing (but rather old and needing much revision) TKEY mechanism and either TSIG or a cryptographic packaging mechanism TBS. It would also be possible to adapt either DTLS or IPSEC. But neither of those is well suited to use as a security wrapper for DNS for reasons I won't go into here. On Sun, Sep 26, 2010 at 12:26 PM, Tony Finch d...@dotat.at wrote: On 25 Sep 2010, at 01:16, John Levine jo...@iecc.com wrote Plan C: Sophisticated ISPs might configure their own DNSSEC key into customer resolvers, and sign replacement records with that. DNSSEC's validation model makes this basically impossible. The customer resolvers would have to know ahead of time which names will be overridden by their ISP and so may be validated by the extra trust anchor. Plan D: ISPs that want to block the DNS for evil domains just return a server failure response for the appropriate queries. See also Paul Vixie's RPZ proposal. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF-meta (was: Fisking vs Top-Posting)
On Mon Sep 27 15:37:56 2010, Richard L. Barnes wrote: This group is dedicated to the discussion of ancillary issues of interest to the IETF community, especially discussions about how IETF discussions and meetings should work. Oh, I thought it was the technical rubbish that was off-topic here. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote: DNSSEC is a mechanism for establishing inter-domain trust. It is not an appropriate technology for intra-domain trust. Why not? Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Roll] Last Call: draft-ietf-roll-rpl-11.txt IPR Concern
I'm not closely involved with ROLL but I am working on devices using the CORE work that would likely make use of and depend on this protocol. I have some concerns about the practically of using ROLL given the IPR. My understanding of the IPR is that one would be required to use certificates that are from an CA license by Certicom. My belief is that the many of the low cost devices that would want to implement ROLL would be based on Linux implementation as that has become one of the most widely used operating systems for low cost networking devices such as residential routers. Given the optimal ways of integrating a protocol such as this into the kernel, and the issues of likening such as this in GPL code, I really wonder if the current IPR will be a major determent to deployment of ROLL. It's not easy to search the archives and I easily could have missed things but I can not find any significant discussion of it the WG could avoid this IPR. There were a few emails in July but it did not seem like it really hit this topic. I would have expected to see discussion on such topics as David McGrews draft on Fundamental Elliptic Curve Cryptography Algorithms or perhaps using RSA approaches. I think discussion about this IPR, and ways it could be avoided, would be appropriate before approving this draft. Cullen On Aug 18, 2010, at 4:28 PM, The IESG wrote: The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'RPL: IPv6 Routing Protocol for Low power and Lossy Networks' draft-ietf-roll-rpl-11.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-09-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ The following IPR Declarations may be related to this I-D: /ipr/1270/ /ipr/1356/ /ipr/1366/ ___ Roll mailing list r...@ietf.org https://www.ietf.org/mailman/listinfo/roll Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
On 27September2010Monday, at 7:48, Tony Finch wrote: On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote: DNSSEC is a mechanism for establishing inter-domain trust. It is not an appropriate technology for intra-domain trust. Why not? Because the atomic unit of DNSSEC is a domain/zone/delegation, not a specific RRset. Everything in a domain has the exact same threat model. --bill Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ 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
IAOC Administrative Procedure Published
The IAOC approved it's updated administrative procedures on 16 September 2010. They can be found at: http://iaoc.ietf.org/docs/IAOC-Administrative-Procedures-9-16-2010.pdf The change from what was discussed on this list was to add a requirement that any reimbursement of expenses to IAOC members for IAOC expenses will be reported in the minutes. Bob Hinden IAOC Chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
US DoD and IPv6
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris Strance,
the chief of internet protocol for the [Dod], as saying:
{the DoD} philosophy is one that when a component has a mission need or a
business case to move to IPv6, then they can do that ... It's driven by
their need rather than an overall [Department of Defense] mandate.
(The complete article is at:
http://www.defense.gov/news/newsarticle.aspx?id=59780
This seems a significant change in course from that given in the Internet
Protocol Version 6 (IPv6) Interim Transition Guidance of September 29, 2003,
which said that:
the DoD has established the goal of transitioning all DoD networking to
the next generation of the Internet Protocol, IPv6, by fiscal year (FY)
2008.
The date slippage is not a big deal, I'm ignoring that. What is of more
interest is that it appears (from the news story) that there has been a
further* change of course on IPv6 adoption, from 'we _are_ going to
transition' to 'in cases where there is a monetary or operational case to
convert, it will happen, but otherwise not'.
Can anyone shed any light on this apparent change in policy?
Noel
-
* The only other policy course change I am aware of is the one from August
16, 2005 (Internet Protocol Version 6 (IPv6) Policy Update), which said
that:
... waiver submissions for programs not transitioning to IPv6 by FY2008.
Henceforth, IPv6 waivers are not required by DoD CIO policy.
(The original September 29, 2003 policy had said If the IPv6 capable
criteria {for any DoD acquistion} cannot be met, a waiver will be required.)
I suppose that technically the seeming current course fits within that updated
policy, but it still seems to be a change in emphasis and direction.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: US DoD and IPv6
On Sep 27, 2010, at 7:31 PM, Noel Chiappa wrote:
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris Strance,
the chief of internet protocol for the [Dod], as saying:
{the DoD} philosophy is one that when a component has a mission need or a
business case to move to IPv6, then they can do that ... It's driven by
their need rather than an overall [Department of Defense] mandate.
(The complete article is at:
http://www.defense.gov/news/newsarticle.aspx?id=59780
This seems a significant change in course from that given in the Internet
Protocol Version 6 (IPv6) Interim Transition Guidance of September 29, 2003,
which said that:
the DoD has established the goal of transitioning all DoD networking to
the next generation of the Internet Protocol, IPv6, by fiscal year (FY)
2008.
The date slippage is not a big deal, I'm ignoring that. What is of more
interest is that it appears (from the news story) that there has been a
further* change of course on IPv6 adoption, from 'we _are_ going to
transition' to 'in cases where there is a monetary or operational case to
convert, it will happen, but otherwise not'.
Does this surprise anyone with experience with the DOD ? It doesn't me.
Regards
Marshall
Can anyone shed any light on this apparent change in policy?
Noel
-
* The only other policy course change I am aware of is the one from August
16, 2005 (Internet Protocol Version 6 (IPv6) Policy Update), which said
that:
... waiver submissions for programs not transitioning to IPv6 by FY2008.
Henceforth, IPv6 waivers are not required by DoD CIO policy.
(The original September 29, 2003 policy had said If the IPv6 capable
criteria {for any DoD acquistion} cannot be met, a waiver will be required.)
I suppose that technically the seeming current course fits within that updated
policy, but it still seems to be a change in emphasis and direction.
___
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
On 2010-09-28 13:59, Marshall Eubanks wrote:
On Sep 27, 2010, at 7:31 PM, Noel Chiappa wrote:
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris Strance,
the chief of internet protocol for the [Dod], as saying:
{the DoD} philosophy is one that when a component has a mission need or a
business case to move to IPv6, then they can do that ... It's driven by
their need rather than an overall [Department of Defense] mandate.
(The complete article is at:
http://www.defense.gov/news/newsarticle.aspx?id=59780
This seems a significant change in course from that given in the Internet
Protocol Version 6 (IPv6) Interim Transition Guidance of September 29, 2003,
which said that:
the DoD has established the goal of transitioning all DoD networking to
the next generation of the Internet Protocol, IPv6, by fiscal year (FY)
2008.
The date slippage is not a big deal, I'm ignoring that. What is of more
interest is that it appears (from the news story) that there has been a
further* change of course on IPv6 adoption, from 'we _are_ going to
transition' to 'in cases where there is a monetary or operational case to
convert, it will happen, but otherwise not'.
Does this surprise anyone with experience with the DOD ? It doesn't me.
It sound to me like a case for the phrase often used by my late colleague
Mervyn Hine at CERN, when the management performed a U-turn: Aha! Reality has
broken in again.
The fact is that official mandates are not a very good reason for
upgrading systems. Running out of a resource is a much better one.
http://www.potaroo.net/tools/ipv4/
Brian
Regards
Marshall
Can anyone shed any light on this apparent change in policy?
Noel
-
* The only other policy course change I am aware of is the one from August
16, 2005 (Internet Protocol Version 6 (IPv6) Policy Update), which said
that:
... waiver submissions for programs not transitioning to IPv6 by FY2008.
Henceforth, IPv6 waivers are not required by DoD CIO policy.
(The original September 29, 2003 policy had said If the IPv6 capable
criteria {for any DoD acquistion} cannot be met, a waiver will be required.)
I suppose that technically the seeming current course fits within that
updated
policy, but it still seems to be a change in emphasis and direction.
___
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
Phill,
On 2010-09-28 16:25, Phillip Hallam-Baker wrote:
The US DoD is running out of IPv4 space?
Where did I say that?
I very much doubt it.
Maybe, maybe not... how would we know?
Problem with the idea that resource depletion will drive adoption of IPv6 is
that it ignores the fact that people who have plenty of IPv4 addresses may
not be that worried about the inability of others to get hold of them.
Sure, and those people can live in their own little world, until
something changes. Then, they either have a plan in place, or they panic.
And some people are going to see ways of keeping out the competition. Their
view of IPv4 will like the view of the medallion owners who keep New York
Taxis expensive and hard to find even though there is no shortage of drivers
willing to work.
Yes, just as incumbent telcos fought against the Internet twenty years
ago, until something changed.
The reason IPv6 is still at the project stage is that the designers had the
wrong view of economics. You don't make IPv6 attractive by making it
different to IPv4, you make it attractive by eliminating all the
differences.
If only life was that simple, Phill. In any case, we can't rewrite history,
and many operators are well beyond project and well into plan.
Content providers who aren't into plan have a problem coming up if they
still want to grow their audience a few years from now.
Brian
On Mon, Sep 27, 2010 at 10:20 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
On 2010-09-28 13:59, Marshall Eubanks wrote:
On Sep 27, 2010, at 7:31 PM, Noel Chiappa wrote:
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris
Strance,
the chief of internet protocol for the [Dod], as saying:
{the DoD} philosophy is one that when a component has a mission need
or a
business case to move to IPv6, then they can do that ... It's driven by
their need rather than an overall [Department of Defense] mandate.
(The complete article is at:
http://www.defense.gov/news/newsarticle.aspx?id=59780
This seems a significant change in course from that given in the
Internet
Protocol Version 6 (IPv6) Interim Transition Guidance of September 29,
2003,
which said that:
the DoD has established the goal of transitioning all DoD networking
to
the next generation of the Internet Protocol, IPv6, by fiscal year (FY)
2008.
The date slippage is not a big deal, I'm ignoring that. What is of more
interest is that it appears (from the news story) that there has been a
further* change of course on IPv6 adoption, from 'we _are_ going to
transition' to 'in cases where there is a monetary or operational case
to
convert, it will happen, but otherwise not'.
Does this surprise anyone with experience with the DOD ? It doesn't me.
It sound to me like a case for the phrase often used by my late colleague
Mervyn Hine at CERN, when the management performed a U-turn: Aha! Reality
has
broken in again.
The fact is that official mandates are not a very good reason for
upgrading systems. Running out of a resource is a much better one.
http://www.potaroo.net/tools/ipv4/
Brian
Regards
Marshall
Can anyone shed any light on this apparent change in policy?
Noel
-
* The only other policy course change I am aware of is the one from
August
16, 2005 (Internet Protocol Version 6 (IPv6) Policy Update), which
said
that:
... waiver submissions for programs not transitioning to IPv6 by
FY2008.
Henceforth, IPv6 waivers are not required by DoD CIO policy.
(The original September 29, 2003 policy had said If the IPv6 capable
criteria {for any DoD acquistion} cannot be met, a waiver will be
required.)
I suppose that technically the seeming current course fits within that
updated
policy, but it still seems to be a change in emphasis and direction.
___
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
Re: US DoD and IPv6
GOSIP http://tools.ietf.org/html/rfc1039 Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Media Type Registration Reviews - Standards Tree/No Internet Draft
The IESG has approved a request to register image/ktx MIME media types in the standards tree. This media type is a product of the Khronos Group (www.khronos.org). The IESG contact persons are Alexey Melnikov and Peter Saint-Andre. The registration template can be found at this location: http://www.khronos.org/opengles/sdk/tools/KTX/file_format_spec/#mimeregistration The original registration template was submitted as: http://www.alvestrand.no/pipermail/ietf-types/attachments/20100831/df8a3724/attachment.txt An archive of the discussion can be found here: http://www.alvestrand.no/pipermail/ietf-types/2010-August/002385.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Overview and Framework for Internationalized Email' to Informational RFC
The IESG has approved the following document: - 'Overview and Framework for Internationalized Email' draft-ietf-eai-frmwrk-4952bis-10.txt as an Informational RFC This document is the product of the Email Address Internationalization Working Group. The IESG contact persons are Alexey Melnikov and Peter Saint-Andre. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-frmwrk-4952bis/ Technical Summary Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is an update of RFC 4952; it reflects additional issues identified since that document was published. Working Group Summary There were nothing controversal nor even rough for this document. Document Quality This document does not describe any protocols in detail, that belongs to other documents. Ernie Daindow, Tony Hansen, Shawn Steele, and Jiankang Yao reviewed the document thoroughly and suggested text to improve it. The general protocol collection described in this document derives from prior Experimental protocols that were implemented and tested. The results of those experiments, focusing on what should be done differently as a result, are discussed in this document. At least those who implemented the Experimental protocols, and presumably some others, are likely to implement the standards-track protocols as soon as they are considered stable. There appears to be significant worldwide demand for the facilities being specified by the EAI WG and outlined in this document. Personnel Joseph Yee is the Document Shepherd. Alexey Melnikov is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'An Architecture for Network Management using NETCONF and YANG' to Informational RFC
The IESG has approved the following document: - 'An Architecture for Network Management using NETCONF and YANG ' draft-ietf-netmod-arch-10.txt as an Informational RFC This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-arch-10.txt Technical Summary NETCONF gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. Working Group Summary This document represents strong consensus of the working group after intense work over the last 18 months. This document has been worked through very carefully by all key players in the working group. Document Quality This document has been worked through very carefully by all key players in the working group. Personnel David Partain is the Document Shepherd. Dan Romascanu is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IAOC Administrative Procedure Published
The IAOC approved it's updated administrative procedures on 16 September 2010. They can be found at: http://iaoc.ietf.org/docs/IAOC-Administrative-Procedures-9-16-2010.pdf The change from what was discussed on the IETF list was to add a requirement that any reimbursement of expenses to IAOC members for IAOC expenses will be reported in the minutes. Bob Hinden IAOC Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'PKCS #5 Password Based Key Derivation Function 2 (PBKDF2) Test Vectors' to Informational RFC
The IESG has approved the following document: - 'PKCS #5 Password Based Key Derivation Function 2 (PBKDF2) Test Vectors ' draft-josefsson-pbkdf2-test-vectors-06.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Sean Turner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-josefsson-pbkdf2-test-vectors-06.txt Technical Summary This document contains test vectors for the Public-Key Cryptography Standards (PKCS) #5 Password Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA-1) pseudorandom function. Working Group Summary This is not the product of a WG. Document Quality There are at least four known implementations that confirmed these test vectors. Personnel Simon Josefsson si...@josefsson.org is the Document Shepherd. Sean Turner turn...@ieca.com is the sponsoring Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
[no subject]
rfc-...@rfc-editor.org Subject: Re: Experimental RFC to be: draft-dzis-nwg-nttdm-04.txt The IESG has no problem with the publication of 'The Network Trouble Ticket Data Model' draft-dzis-nwg-nttdm-04.txt as an Experimental RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18533rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Peter Saint-Andre. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dzis-nwg-nttdm-04.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary This document defines an experimental XML format for communication of trouble tickets among network operation centers (NOCs). This format enables NOCs to automate the collection, communication, and synchronization of trouble tickets across multiple interconnected networks, such as those forming the Grid. The model was defined and used as part of the networking support activity of the EGEE project (Enabling Grids for E-sciencE). Working Group Summary This document is an independent submission and is not the product of (nor has it been reviewed by) any IETF working group. Document Quality The document appears to accurately document the experimental XML format in use. Personnel The responsible Area Director is Peter Saint-Andre. RFC Editor Note This specification documents an XML format that solves a problem similar to those addressed by the INCH and MARF working groups. However, the format serves a somewhat different purpose and thus the IESG has concluded that there is no conflict between this document and IETF work. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Experimental RFC to be: draft-dzis-nwg-nttdm-04.txt
The IESG has no problem with the publication of 'The Network Trouble Ticket Data Model' draft-dzis-nwg-nttdm-04.txt as an Experimental RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18533rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Peter Saint-Andre. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dzis-nwg-nttdm-04.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary This document defines an experimental XML format for communication of trouble tickets among network operation centers (NOCs). This format enables NOCs to automate the collection, communication, and synchronization of trouble tickets across multiple interconnected networks, such as those forming the Grid. The model was defined and used as part of the networking support activity of the EGEE project (Enabling Grids for E-sciencE). Working Group Summary This document is an independent submission and is not the product of (nor has it been reviewed by) any IETF working group. Document Quality The document appears to accurately document the experimental XML format in use. Personnel The responsible Area Director is Peter Saint-Andre. RFC Editor Note This specification documents an XML format that solves a problem similar to those addressed by the INCH and MARF working groups. However, the format serves a somewhat different purpose and thus the IESG has concluded that there is no conflict between this document and IETF work. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
