[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,
Here I have some comments to draft-ietf-v6ops-security-overview-00.txt
For Section 4.2:
An addional reason why IPv6 by Default may brings the usability down:
- At enterprises, at service providers or even at universities, in most
cases the high availability is a big demand. The HA solutions nowadays
are implemented only for IPv6. There lack of real IPv6 support for HSRP,
VRRP (Virtual router reduncdancy protocol) [RFC3768] and even LVS (Linux
Virtual Server) [LVSURL], that makes IPv6 services less robust.
For Section 4.5:
I would rewrite it in a following way:
-----8<------------------------------------8<--------
It is very common (although questionable) practice to filter completely
the ICMP messages in IPv4. This is no longer possible with IPv6. As the
name that it stands for suggests, Internet Control Message Protocol for
IPv6 [RFC2463] is the control and foundation protocol for the operation of
IPv6, not an auxiliary protocol that can be easily omitted. Our
recommendation is the following:
o ICMPv6-echo-request and reply (Types 128 and 129):
o You can consider enabling at least outgoing
ICMPv6-echo-request and their answers, the ICMPv6-echo-reply
packets to facilitate debugging. Of course, it is wise to rate
limit ICMPv6 debugging packets to a certain level.
o You may consider enable incoming ICMPv6-echo-request packets
and their answers to your well know IPv6 service machines. You
should be sure, however, that your IPv6 service machine can handle
ICMPv6 requests at a certain rate. Of course, it is wise to rate
limit ICMPv6 debugging packets to a certain level.
o ICMPv6-destination-unreachable (Type 1):
o You should consider enabling incoming ICMPv6 destination
unreachable messages for debugging purpuse as an answers to
outgoing IPv6 packets that have been sent out. This should be
implemented with stateful packet inspection mechnanism as
described in 4.5.1.
o You may generate and enable outgoing ICMPv6 destination
unreachable messages for all filtered packets. This is
useful for debugging. It is a common practice in IPv4, to refrain
from generating ICMPv6-destination-unreachable messages to hide
the networking/service structure. You can apply the same rule
to IPv6. If you generate ICMPv6-destination-unreachable
messages, however, do it properly, setting the right reason
code: no route to destination, administratively prohibited, beyond
scope of source address, address unreachable, port unreachable.
o ICMPv6 packet too big (Type 2):
o You must enable incoming ICMPv6-packet-too-big messages as
answers to outgoing IPv6 packets for the Path-MTU-discovery to
operate properly.
o You must generate and allow outgoing ICMPv6-packet-too-big
messages properly if your MTU is different anywhere within your
network from the MTU on the link between you and your provider.
So be prepared, to forward ICMPv6-packet-too-big messages at the
firewall.
o ICMPv6-time-exceeded (Type 3):
o You must/should enable incoming ICMPv6-time-exceeded messages to
be able discover destination systems not reachable due to a low
TTL value in the outgoing packets. This should be implemented with
stateful packet inspection mechanisms to allow only answers to
sent out packet packets.
o You can generate and allow outgoing ICMPv6-time-exceeded
messages since they are essential for proper operation
of Internet.
o ICMPv6-parameter-problem (Type 4):
o You should consider enabling incoming ICMPv6-parameter-problem
messages as answers to outgoing IPv6 packets for debugging purpose.
o You must generate correct and enable outgoing
ICMPv6-parameter-problem messages since they are essential for
proper operation of Internet.
Needs futher investigation since it can be used to scan
services/networks if the attacker deliberatley sending packets with
wrong headers.
o ICMPv6-Neighbour-Solicitation and Neighbour-Advertisement (Type 135 and
136):
o You must enable incoming and outgoing ICMPv6 Neighbour-Solicitation,
Neighbour-Advertisement packets, with proper link-local addresses or
solicited node multicast addresses for the Neighbour Discovery
function to operate properly.
o ICMPv6-Router-Solicitation and Router-Advertisement (Type 133 and 134):
o If the Stateless Address Autoconfiguration function is used, you
must enable outgoing ICMPv6 Router-Advertisement packets, with
proper link-local addresses and multicast addresses (All node
multicast addresses ff02::1).
o If the Stateless Address Autoconfiguration function is used, you
must enable incoming ICMPv6-Router-Solicitation packets, with proper
link-local addresses and multicast addresses (All router multicast
addresses ff02::2).
o ICMPv6-redirect (Type 137):
o You should disallow ICMPv6-router-redirect messages passing, if you
have only one exit router. However, router redundancy might be
implemented by router-redirect. It is important to know that
redirect has link-local meaning only.
o ICMPv6 MLD listener query, listener report and listener done (Type 130,
131 and 132):
o You should enable incoming and outgoing ICMPv6 MLD messages, with
proper link-local addresses or multicast addresses if you want to use
IPv6 multicast on a bigger scope than link-local. This is required
if the "internet-router-firewall-protected network" architecture is
used. In this case your firewall should act as an MLD router.
o ICMPv6-renumbering (Type 138):
o You can disallow ICMPv6 router renumbering messages passing, since
router renumbering is not widely adopted.
o ICMPv6 node information query and reply (Type 139 and 140):
o You may disallow ICMPv6 node information query and reply processing,
since node information query/reply is not widely adopted.
-----8<------------------------------------8<--------
One issue is not discussed sufficiently:
2.1.13 Adress configuration Security (only suggested section number)
Common method in IPv6 to supply an address for a (default) gateway and
other paramaters related to links is through Stateless Address
AutoConfiguration [RFC2462], DHCPv6 [RFC3646] or static configuration.
2.1.13.1 Fake router advertisments
Routers consider authoritative the information carried in router
advertisements sent by other on-link routers, even though such
information is not cryptographically secured (e.g., digitally signed or
key-MACed or encrypted). Clients update the advertised
communication parameters accordingly, without any verification. In the
absence of any verification of the received information, malicious nodes
may inject bogus values for optional fields of the ICMPv6 extension
header, such as the advertised prefix, link layer address address of
next-hop router, HopLimit, various times for addresses or MTU.
However there are some protection to prevent abuse:
- link MTU cannot be lower than 1280 according RFC2460 [RFC2460]
- the HopLimit cannot be lower than 32?
- Variauos constrains to address times
A possible counter-measure that system/network administrators can query
(all routers link local address) ff02::2 constantly in order to identify
any "alien router" on the network segment or log router advertisement
messages. These type of solution is not an ideal one because it can only
warn about an anomaly, not really being able to prevent or correct it.
Alternatively criptographical secured router advertisment should be
implemented.
The use of DHCPv6 systems may also assist in preventing such rogue
configurations.
2.1.13.2 False DHCPv6 server
TBD
2.1.13.3 Mismatching link-local and static parameters
- maintainenance cost <- if renumbering or router change
---
I hope this can improve the draft.
Kindest Regards,
Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98
On Fri, 13 May 2005, Elwyn Davies wrote:
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
Internet-Drafts@ietf.org wrote:
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
i-d-announce-request@ietf.org 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:
mailserv@ietf.org.
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.