[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please comment on new draft: draft-ietf-v6ops-security-overview-00.txt



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 <elwynd@dial.pipex.com> wrote:

<snip>

> Please let us have any comments asap - we intend to produce another new 
> 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.