[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-vives-v6ops-ipv6-security-ps-01 comments
Hi Pekka,
See my comments in-line, below.
Regards,
Jordi
---- Original Message ----
From: "Pekka Savola" <pekkas@netcore.fi>
To: <v6ops@ops.ietf.org>
Sent: Sunday, August 01, 2004 8:04 AM
Subject: draft-vives-v6ops-ipv6-security-ps-01 comments
> Hi,
>
> A couple of comments..
>
> semi-substantial
> ----------------
>
> This model is based on the following assumptions:
>
> o The threats come from "outside" the FW, basically the Internet.
>
> ==> this doesn't yet reflect that there could be multiple FW's, so maybe
> reword to something like:
>
> o The threats come from "outside" the FW(s), basically the Internet or
> some other internal network behind a different FW.
Ok.
>
> ...
>
> o The protected nodes won't go "outside" where FW won't be able to
> protect them.
>
> ==> maybe add at the end: ", and then later come back in, unknowingly
> compromising the rest of the network."
Ok.
>
> o Enables better protection from attacks by the "internal" users,
> and possibly even to a degree from those in the local segment.
> For example address spoofing can be detected and avoided coming
> from the same LAN segment, whitout router participation.
>
> ==> I didn't quite understand this advantage of the distributed model.
> The last sentence doesn't seem to be true, or I don't understand it. I
> mean, the host doesn't really know whether a packet it received was
> spoofed -- whether it was received from Internet through a router, or
> from a legitimate local host in the same LAN, or a host in the same LAN
> spoofing the packet, right?
Or appearing as coming from Internet, but actually coming from the same LAN ?
>
> o A host that becomes compromised or infected with a worm or virus
> in any case can't be trusted to operate according to the policies,
> as the worms/viruses probably first create holes or disable the
> protections if they can.
>
> ==> This also needs to have additional problem why this is severe; add
> e.g., Further, such compromises or
> infections are often built such that they exploit a bug in the local
> system, gaining super-user privileges, which allow them to do more
> than even the user could.
Ok.
>
> Editorial:
> ----------
>
> ==> Abstract is too long, should be cut to something like 30% of its
> current length (IMHO).
Ok. To be done in next version.
>
> In this section two different approaches are analyzed to be used
> later in the rationale about the security problems that IPv6 could
> introduce
>
> ==> add '.' at the end.
Ok.
>
> The biggest challenge, however, is trusting that the hosts comply to
> the rules they've received, for example that the user can't just
> disable the firewall if (s)he dislike the policy; of course, this
> only can happen in the case (s)he has administrative rights for that
> (often not the case in non-personal systems, those not owned by the
> end user). It seems that one ore more network entities would have to
>
> ==> s/dislike/dislikes/
Ok.
> ==> s/ore/or/
Ok.
>
> For example address spoofing can be detected and avoided coming
> from the same LAN segment, whitout router participation.
>
> ==> s/whitout/without/
Ok.
>
> o The hosts must be trusted (or designed appropriately) so that they
> will operate according to the policy. For example, it must be
> impossible to disable the firewall functions or if the policy is
> not followed network communication is not allowed.
>
> ==> s/is not/must not be/ (just to make it stronger)
Ok.
>
>
> [8] Nikander, P., "IPv6 Neighbor Discovery trust models and
> threats", draft-ietf-send-psreq-04 (work in progress), October
> 2003.
>
> ==> this is now RFC
Ok.
**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line 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.