ICANN/DNSO
DNSO Mailling lists archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] Overcoming IPv6 Security Threat


Allan and all assembly members,

  Allan, perhaps as I missed such laughing off of Joe's paper that you
state happened, a reference for such laughing off?  I monitor Nanog,
as do a number of our members, and I personally did not see
such that you claim occurring.  I also did a search of the Nanog
archives, and also came up empty as to you claim.

  What has been stated by Richard Clark, is that they are now
very much concerned about the privacy aspect of the security
problems with IPv6 and that a number of the large ISP's
are not interested, including Mindspring, my ISP, in IPv6
for the privacy and associated security holes in IPv6.
Hence, I fail to see you contention here as being one
that has real merit.

Allan Liska wrote:

> Eric and Others,
>
> Please keep in mind that Joe Baptista was laughed off Nanog when he
> presented his paper there.  If the network operators for the world's
> largest ISPs don't feel there are serious security flaws in IPv6, then
> perhaps the work of Mr. Baptista should be viewes as suspect.
>
> allan
> --
> Allan Liska
> allan@allan.org
> htt://www.allan.org
>
> On Mon, 7 Oct 2002 eric@hi-tek.com wrote:
>
> > Dear Dr. Joe and Alexander,
> >
> > It is completely and directly our responsibility to address these issues.
> > IPv6 is a dangerous and onerous debacle thrust upon us by people who could not
> > recognize failure and then when they did, covered it up with lies and deceit.  How
> > addresses resolve and our security is completely within our purview.
> > Alexander, who is paying you?  Or are you just ignorant?  How could resolutions of
> > domain names not be within the GA mandate?  Why don't you just get a IPv6 and
> > check out your security levels and let someone hack you in ten minutes or monitor
> > your connection.  Is security of domain names germane to the DNSO?
> >
> > Yikes!
> > eric
> >
> > Joe Baptista wrote:
> >
> > > Alexander I disagree - these issues of are importance to the GA.
> > >
> > > As a member I'm concerned about whats happening to internet protocol
> > > number - the attempted commercialization etc.  So should the membership of
> > > the GA be very concerned - the ASO lists amount to not much more then
> > > window dressing.  the people who these changes will afect are here.
> > >
> > > regards
> > > joe baptista
> > >
> > > On Thu, 12 Sep 2002, Alexander Svensson wrote:
> > >
> > > >
> > > > Hello Joe,
> > > >
> > > > this is stuff for the ASO policy mailing list.
> > > > Please stick to DNSO issues on the DNSO list.
> > > >
> > > > Regards,
> > > > /// Alexander
> > > >
> > > > At 12.09.2002 10:37, Joe Baptista wrote:
> > > > >Thanks to everyone who helped out.
> > > > >
> > > > >cheers
> > > > >joe baptista
> > > > >
> > > > >
> > > > >>http://www.circleid.com/articles/2533.asp
> > > > >>
> > > > >>Overcoming IPv6 Security Threat
> > > > >>
> > > > >>September 12, 2002  |  By Joe Baptista
> > > > >>
> > > > >>Technology rags and industry pundits see IPv6 (Internet Protocol version
> > > > >>6) as the future of networking, but Daniel Golding a participant of the
> > > > >>North American Network Operators' Group (NANOG) thinks it's a "solution in
> > > > >>search of a problem". Many others have argued IPv6 is a problem in itself
> > > > >>and it is unlikely the protocol will gain wide acceptance in the short
> > > > >>term.
> > > > >>
> > > > >>IPv6 does solve many of the problems with the current version of IPv4
> > > > >>(Internet Protocol version 4). Its purpose is to expand address space and
> > > > >>fix the IPv4 address depletion problem, which many techies claim, was due
> > > > >>to mismanagement. The industry's goal is to use the very large address
> > > > >>allocation pool in IPv6 to expand the capabilities of the Internet to
> > > > >>enable a variety of peer-to-peer and mobile applications including
> > > > >>cellular phone technology and home networking.
> > > > >>
> > > > >>IPv6, a suite of protocols for the network layer, uses IPv4 gateways to
> > > > >>interconnect IPv6 nodes and comes prepackaged with some popular operating
> > > > >>systems. This includes almost all Unix flavors, some Windows versions and
> > > > >>Mac OS. Some vendors offer upgrades to older operating systems. Trumpet
> > > > >>Software International in Tasmania Australia manufactures a Trumpet
> > > > >>Winsock version that upgrades old Windows 95/98 and NT systems to the
> > > > >>current IPv6 standard.
> > > > >>
> > > > >>IPv6 has suffered bad press over privacy issues. Jim Fleming, the inventor
> > > > >>of IPv8, a competing protocol, sees many hazards and privacy flaws in
> > > > >>existing IPv6 implementations. IPv6 address space in some cases uses an ID
> > > > >>(identifier) derived from your hardware or phone "that allows your packets
> > > > >>to be traced back to your PC or cell-phone" said Fleming. Potential abuse
> > > > >>to user privacy exists as a hardware ID wired into the IPv6 protocol can
> > > > >>be used to determine the manufacturer, make and model number, and value of
> > > > >>the hardware equipment being used. Fleming warns users to think twice
> > > > >>before they buy themselves a used Laptop computer and inherit all the
> > > > >>prior surfing history of the previous user!
> > > > >>
> > > > >>IPv6 uses 128 bits to provide addressing, routing, and identification
> > > > >>information on a computer interface or network card. The 128 bits are
> > > > >>divided into the left 64 and the right 64. Some IPv6 systems use the right
> > > > >>64 bits to store an IEEE defined global identifier (EUI64). This
> > > > >>identifier is composed of company id value assigned to a manufacturer by
> > > > >>the IEEE Registration Authority. The 64-bit identifier is a concatenation
> > > > >>of the 24-bit company identification value and a 40-bit extension
> > > > >>identifier assigned by the organization with that company identification
> > > > >>assignment. The 48-bit MAC address of your network interface card may also
> > > > >>be used to make up the EUI64.
> > > > >>
> > > > >>In the early stages of IPv6 development, Bill Frezza a General Partner
> > > > >>with the venture capital firm, Adams Capital Management warned software
> > > > >>developers that if privacy issues are not properly addressed, the
> > > > >>migration to IPv6 "will blow up in their face"! Leah Gallegos agrees that
> > > > >>while "expanding the address space is necessary the use of the address for
> > > > >>ID and tracking is horrific". Gallegos the operator of the top-level
> > > > >>domain .BIZ and a Director of the Top Level Domain Association cautions
> > > > >>network administrators that they should refuse to implement IPv6 unless
> > > > >>these issues are properly addressed.
> > > > >>
> > > > >>Privacy concerns prompted the creation of new standards, which provide
> > > > >>privacy extensions to IPv6 devices. Thomas Narten and Track Draves of
> > > > >>Microsoft Research published a procedure to ensure privacy of IPv6 users.
> > > > >>Narten, IBM's technical lead on IPv6 and an Area Director for the Internet
> > > > >>Engineering Task Force (IETF), agrees "IPv6 address can, in some cases,
> > > > >>include an identifier derived from a hardware address". But Narten points
> > > > >>out that a hardware address is not required. "In cases where using a
> > > > >>permanent identifier is a problem", said Narten "RFC 3041 addresses should
> > > > >>be used".
> > > > >>
> > > > >>RFC 3041 titled "Privacy Extensions for Stateless Address
> > > > >>Autoconfiguration in IPv6" was published this past January 2001 by the
> > > > >>IETF. It is an algorithm developed jointly by Narten and Draves which
> > > > >>generates randomized interface identifiers and temporary addressees during
> > > > >>a user session. This would eliminate the concerns privacy advocates have
> > > > >>with IPv6.
> > > > >>
> > > > >>Unfortunately RFC 3041 is not widely implemented. But Narten expects major
> > > > >>vendors to incorporate his privacy standard and offered that Microsoft
> > > > >>implemented privacy extensions "and apparently intends to make it part of
> > > > >>their standard stuff". Narten also assisted in the drafting of
> > > > >>recommendations for some second and third generation cellular phones
> > > > >>recently approved for publication by the Internet Engineering Steering
> > > > >>Group. That document recommends that RFC 3041 be implemented as part of
> > > > >>cellular phone technology but he did not know what direction cell phones
> > > > >>manufacturers were taking. "I suspect that client vendors will generally
> > > > >>implement it because of the potential bad PR if they don't" said Narten.
> > > > >>
> > > > >>Another obstacle raised by NANOG operators is that there is currently no
> > > > >>commercial demand for IPv6 at this time. Dave Israel, a Data Network
> > > > >>Engineer and regular participant on NANOG lists, sees no immediate demand
> > > > >>for IPv6 services. "The only people who ask me about IPv6", said Israel
> > > > >>"are people who have heard something about it from some tech-magazine and
> > > > >>want the newest thing". Israel says he sees no commercial demand for a v6
> > > > >>backbone.
> > > > >>
> > > > >>Daniel Golding, another NANOG participant agrees, "v6 deployment is being
> > > > >>encouraged by some countries, and the spread of 3G (cellular technology)
> > > > >>is helping things along, but we have yet to see really widespread v6
> > > > >>deployments anywhere". Golding sees major backbone networks deploying IPv6
> > > > >>when it makes economic sense for them to do so. "Right now", said Golding
> > > > >>"there is no demand and no revenue upside. I don't expect this to change
> > > > >>in the near future".
> > > > >>
> > > > >>Most on NANOG agree the roadblock seems to be a lack of ISPs that offer
> > > > >>IPv6 services. Stephen Sprunk, a Network Design Consultant with Cisco's
> > > > >>Advanced Services group sees the "greater adoption of always-on broadband
> > > > >>access will be the necessary push" to get IPv6 off the ground. "Enterprise
> > > > >>networks will not be the driver for ISPs to go to IPv6" said Sprunk and
> > > > >>"NAT is too entrenched". Network Address Translation (NAT) is a method of
> > > > >>connecting multiple computers to the Internet (or any other IP network)
> > > > >>using one IPv4 address.
> > > > >>
> > > > >>Vint Cerf senior vice president of architecture & technology at WorldCom
> > > > >>has been using IPv6 for about four years. IPv6 has been a key element for
> > > > >>some of WorldCom's Government customers. Cerf thinks IPv6 supporters have
> > > > >>a lot of work ahead to achieve successful deployment of the protocol. He
> > > > >>expects "that over the next several years we will see a lot of consumer
> > > > >>devices set up to work with IPv6" and "cell phones are likely candidates,
> > > > >>as are radio-enabled PDAs".
> > > > >>
> > > > >>-EOF
> > > > >
> > > > >The dot.GOD Registry, Limited
> > > > >http://www.dot-god.com/
> > > >
> > >
> > > --
> > > This message was passed to you via the ga@dnso.org list.
> > > Send mail to majordomo@dnso.org to unsubscribe
> > > ("unsubscribe ga" in the body of the message).
> > > Archives at http://www.dnso.org/archives.html
> >
> > --
> > This message was passed to you via the ga@dnso.org list.
> > Send mail to majordomo@dnso.org to unsubscribe
> > ("unsubscribe ga" in the body of the message).
> > Archives at http://www.dnso.org/archives.html
> >
> >
>
> --
> This message was passed to you via the ga@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 127k members/stakeholders strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number: 214-244-4827 or 972-244-3801
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208


--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html



<<< Chronological Index >>>    <<< Thread Index >>>