Subject: I-D ACTION:draft-ietf-v6ops-security-overview-00.txt

From: [email-masked]
Date: Fri, 13 May 2005 15:47:47 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: IPv6 Transition/Co-existence Security Considerations
	Author(s)	: E. Davies, et al.
	Filename	: draft-ietf-v6ops-security-overview-00.txt
	Pages		: 32
	Date		: 2005-5-13
	
The transition from a pure IPv4 network to a network where IPv4 and
   IPv6 co-exist brings a number of extra security considerations that
   need to be taken into account when deploying IPv6 and operating the
   dual-protocol network and the associated transition mechanisms.  This
   document attempts to give an overview of the various issues grouped
   into three categories:
   o  issues due to the IPv6 protocol itself,
   o  issues due to transition mechanisms, and
   o  issues due to IPv6 deployment.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-v6ops-security-overview-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-v6ops-security-overview-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 13 May 2005 21:35:14 +0100

Hi.

A new version of this draft (previously 
draft-savola-v6ops-security-overview) which is now a WG draft is available.

Please let us have any comments asap - we intend to produce another new 
version incorporating any comments prior to IETF-63.

This version incorporates a number of additional points contributed by 
SUZUKI Shinsuke for the Japan IPv6 Promotional Council as well as deal 
of updated wording.  We are particularly interested on views of how we 
should proceed on the subject of ICMPv6 filtering in firewalls.

Thanks,
Elwyn Davies for the authors

---

From: Mark Smith <[email-masked]>
Date: Sat, 28 May 2005 19:36:53 +0930

Hi Elwyn,

I'm reading through it the first time, it looks good.

My $0.02 below.

On Fri, 13 May 2005 21:35:14 +0100
Elwyn Davies <[email-masked]> wrote:

<snip>

> version incorporating any comments prior to IETF-63.

2.1.11  Link-Local Addresses and Securing Neighbor Discovery

"Because the link-local address can, by default, be acquired without
   external intervention or control, it allows an attacker to commence
   communication on the link without needing to acquire information
   about the address prefixes in use or communicate with any authorities
   on the link.  This feature gives a malicious node the opportunity to
   mount an attack on any other node which is attached to this link;
   this vulnerability exists in addition to possible direct attacks on
   NDP."

I think there is also a "non-malicious" use of link local addresses in
the above scenario, in particular on wireless links, namely using the
available link bandwidth to communicate between one or more "non-link
authorised" nodes, rather than maliciously attacking "link-authorised"
nodes. That is eluded to in the earlier part of the paragraph,
possibly an explicit mention of this type of bandwidth theft could be
useful.

2.3.2  Enterprise Network Security Model for IPv6

"   o  Development of centralized security policy repositories and
      distribution mechanisms which, in conjunction with trusted hosts,
      will allow network managers to place more reliance on security
      mechanisms at the end points and allow end points to influence the
      behavior of perimeter firewalls."

My comment is probably a bit minor. The text is abstract about the
security mechanisms on the end-points, yet is specific about the idea of
allowing the end points to influence the perimeter firewalls. I'd like
to suggest either being a bit more specific about end point security
mechanisms (ie. explicit "end-node firewalling"), or be a bit more
abstract about perimeter security mechanisms. It seems to me that the
above paragraph is somewhat implying that the idea of perimeter
firewalls is mostly agreed upon, yet I think that once the end points
implement firewall type security themselves, with a policy distribution
mechanism, perimeter firewalls would possibly be unnecessary. This
end-node firewalling only security model would contradict the "and allow
end points to influence the behavior of perimeter firewalls" text above.
Possibly the "and" could be changed to an "or" ? Again, this point is
probably minor.

B.1  Exposing MAC Addresses

"The MAC address, which with stateless address autoconfiguration,
   results in an EUI64, exposes the model of network card.  The concern
   has been that a user might not want to expose the details of the
   system to outsiders, e.g., in the fear of a resulting burglary (e.g.,
   if a crook identifies expensive equipment from the MAC addresses)."

I've understood the more significant issue that exposing MAC addresses
created wasn't being able to remotely identify the model/manufacturer of
devices, but rather, that as EUI64s were derived from commonly
world-wide unique EUI48s, the node address became a mechanism to allow
tracking the access patterns of nodes, and therefore typically an
individual person, no matter what their attachment point to the
network/Internet, and how often they change it (therefore aquiring a new
/64 prefix). "B.3 Exposing the Site by a Stable Prefix" mentions this
privacy concern, although it seems to be constricting the privacy
concern to a site, which I think tends to imply that if the node leaves
the site, this issue disappears, and I'm pretty sure it doesn't.

That's it for the moment.

Regards,
Mark.

---

From: "Alvaro Vives" <[email-masked]>
Date: Tue, 31 May 2005 17:59:08 +0200

Hi Mark,

I would like to add some comments over your comments... See below: 

> > Please let us have any comments asap - we intend to produce another 
> > new version incorporating any comments prior to IETF-63.
> > 
> 
> I think there is also a "non-malicious" use of link local 
> addresses in the above scenario, in particular on wireless 
> links, namely using the available link bandwidth to 
> communicate between one or more "non-link authorised" nodes, 
> rather than maliciously attacking "link-authorised"
> nodes. That is eluded to in the earlier part of the 
> paragraph, possibly an explicit mention of this type of 
> bandwidth theft could be useful.

This is an interesting idea and IMO not restricted to wireless links. I
think the general idea is that link-local addresses allows communication
among hosts within a LAN and no access control could be done. For example in
a layer two infrastructure within a building two hosts could communicate
among them.

> My comment is probably a bit minor. The text is abstract 
> about the security mechanisms on the end-points, yet is 
> specific about the idea of allowing the end points to 
> influence the perimeter firewalls. I'd like to suggest either 
> being a bit more specific about end point security mechanisms 
> (ie. explicit "end-node firewalling"), or be a bit more 
> abstract about perimeter security mechanisms. It seems to me 
> that the above paragraph is somewhat implying that the idea 
> of perimeter firewalls is mostly agreed upon, yet I think 
> that once the end points implement firewall type security 
> themselves, with a policy distribution mechanism, perimeter 
> firewalls would possibly be unnecessary. This end-node 
> firewalling only security model would contradict the "and 
> allow end points to influence the behavior of perimeter 
> firewalls" text above.
> Possibly the "and" could be changed to an "or" ? Again, this 
> point is probably minor.
> 

I would suggest not to just think on end-node firewalling but in a more
complex "security tool" which will enforce the security policy distributed.
I could think in firewalling+IDS+anti-virus+anti-spam+....

Regards,
Alvaro Vives
Consulintel

> I've understood the more significant issue that exposing MAC 
> addresses created wasn't being able to remotely identify the 
> model/manufacturer of devices, but rather, that as EUI64s 
> were derived from commonly world-wide unique EUI48s, the node 
> address became a mechanism to allow tracking the access 
> patterns of nodes, and therefore typically an individual 
> person, no matter what their attachment point to the 
> /64 prefix). "B.3 Exposing the Site by a Stable Prefix" 
> mentions this privacy concern, although it seems to be 
> constricting the privacy concern to a site, which I think 
> tends to imply that if the node leaves the site, this issue 
> disappears, and I'm pretty sure it doesn't.
> 

************************************
Barcelona 2005 Global IPv6 Summit
Registration open. Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.