[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 Mark,
I would like to add some comments over your comments... See below:
> 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.
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.
>
> 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.
>
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
> 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.
>
>
>
>
>
>
************************************
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.