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

From: Mohacsi Janos <[email-masked]>
Date: Mon, 6 Jun 2005 13:15:39 +0200 (CEST)

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
>
> [email-masked] 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 
>> [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: Mohacsi Janos <[email-masked]>
Date: Mon, 6 Jun 2005 18:11:31 +0200 (CEST)

Dear All,

 	Sorry. I sent out earlier version of my comment this morning. I 
had to send it via on an unreliable wireless connection and I selected 
wrong version of the file. I send in an attachment now.
Sorry again.

Janos Mohacsi

On Mon, 6 Jun 2005, Mohacsi Janos wrote:

> - 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:
> 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:
>
> 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.
>
>> A new version of this draft (previously 
>> draft-savola-v6ops-security-overview) which is now a WG draft is available.
>> 
>> 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,