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

RE: Last call comments for draft-ipngwg-icmp-v3-05



Elwyn,

I think the changes you are proposing are outside of the scope of what we are trying to do with this draft (update and recycle at draft standard). The filtering text is close to specifying new behavior that is inappropriate to add at Draft standard. I think it would be better that they be in some sort of broader v6ops filtering document.

I would recommend to the working group that we proceed with the ICMP update without these changes.

Bob





At 08:49 AM 11/19/2004, Elwyn Davies wrote:

Mukesh,

Sorry for the delay in replying.

Responses in line...

> -----Original Message-----
> From: ipv6-bounces@xxxxxxxx [<mailto:ipv6-bounces@xxxxxxxx>mailto:ipv6-bounces@xxxxxxxx]
> Sent: 09 November 2004 00:10
> To: Davies, Elwyn [HAL02:0S00:EXCH]; hinden@xxxxxxxxxxxxxx;
> ipv6@xxxxxxxx
> Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05
>
>
> Elwyn,
>
> Responses inline..
>
> > => I see that the renumbering might be a nuisance..
> > i still think the section would be clearer reordered.
> > i would be happy to divide 2.1 into three 3rd level
> > sections as suggested (ie 2.1.1, ...)
>
> But won't that create inconsistency within the document?
> People will be wondering about why this section was
> broken into the 3rd level? Currently, we don't have
> any section with 3rd level of sub-sections.


I don't think that it would cause very many raised eyebrows, but another way of achieving the original result would be to move the pieces about the type split etc to the end of section 2. A new 2.5 would have the type split text and the messages defined in this doc to a new 2.6. These could be referenced in in 2.1 to help with backwards comaptibility.

>
> > The spec already mentions policy in connection with
> > error messages so we can't totally punt on the 'out
> > of scope' grounds;-).  Is an implementation of ICMP
> > that (for example) doesn't generate Echo Responses
> > when it receives Echo Requests under some
> > circumstances compliant with the standard or not?
> > There is a 'MUST' in 4.1.  Or are we relying on
> > statements elsewhere that the packets can be filtered
> > (and so we need not generate them in the first place)
> > - like node requirements (although this says nothing
> > about ACLs and filtering at present)?
>
> Policy (ACL or filters) can be used to drop "any" packets.
> IMHO, if we start adding disclaimers about the ACLs or
> filters, a disclaimer will be needed in almost every spec.
> Right?
>
> Please propose the specific modification (text and
> location) and then we can have a consensus call about if
> we need to add it in the draft or not.
>

Suggest we add a new sub-section in Section 5 relating to filetering of ICMPv6 messages. I am short of time to compose the exact text at this moment but we need something to reflect the ideas from the v6ops security overview which i have been editing:

4.5  Deploying ICMPv6

   In IPv4 it is generally accepted that stringent filtering of ICMP
   packets by firewalls is essential to maintain security.  Because of
   the extended use that is made of ICMPv6 with a multitude of
   functions, the simple set of dropping rules that are usually applied
   in IPv4 need to be significantly developed for IPv6.  The blanket
   dropping of all ICMP messages that is used in some very strict
   environments is simply not possible for IPv6.

   In an IPv6 firewall, policy needs to allow some messages through the
   firewall but also has to permit certain messages to and from the
   firewall.

   To support effective functioning of IPv6, firewalls should typically
   allow the following messages to pass through the firewall (the first
   four are equivalent to the typical IPv4 filtering allowance):
   o  ICMPv6 Type 1, Code 0 - No route to destination error
   o  ICMPv6 Type 3 - Time exceeded error
   o  ICMPv6 Type 128 - Echo request
   o  ICMPv6 Type 129 - Echo response
   o  ICMPv6 Type 2 - Packet too big (required for Path MTU Discovery)
   o  ICMPv6 Type 4 - Parameter problem (this type needs to be
      investigated further as it is possible that  it can be abused.

   Additionally the following ICMPv6 messages may be required to be
   supported to and from a firewall:
   o  ICMPv6 Type 2 - packet too big - The firewall itself has to
      participate in Path MTU Discovery.
   o  ICMPv6 Type 130-132 - Multicast Listener Discovery messages have
      to be accepted by routing devices to replace IGMP which is used in
      IPv4[Check for MLDv2]
   o  ICMPv6 Type 133/134 - Router Solicitations and Advertisements -
      assuming the firewall is also a router, it needs to support router
      discovery and host auto-configuration.
   o  ICMPv6 Type 135/136 - Neigbor Solicitation and Advertisement -
      Needed for duplicate address detection and Layer 2 address
      resolution.
   o  ICMPv6 Type 4 - parameter Problem - Needs further investigation
      because of possible abuse.

I'll get back with some more precise text asap as this refers to messages outside the scope of this draft so we need some general words here.

Regards,
Elwyn

<<snip>>
[The other two points were agreed i think]


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------