On 2/6/13 3:41 PM, Ronald Bonica wrote:
Ole,
I am supporting this draft because the community has become accustomed to
stateless firewalls on routers. These stateless firewalls are capable of
filtering based upon information gleaned from both the IPv6 and L4 header.
When a stateless firewall encounters an IPv6 datagram in which the IPv6 header
and L4 header don't appear in the first fragment, it can't make an informed
filtering decision on any fragment. However, if there is a guarantee that the
IPv6 header and the L4 header are in the first fragment, it can at least make
an informed decision regarding that fragment.
my own .02
Stateless observation of upper layer headers of any variety have this
issue whether applied in a router or on and end system. if I wish to
apply a particular priority to a packet forwarding on the basis of an L4
identifier I have to find it first. If I want my sflow/netflow export
to expose the contents of the upper layer header I need to find them. If
I want to protect the control plane, first I need to find the upper
layer header. If I need to mitigate a DOS attack sourced on UDP 53 I
need to find the upper layer header etc.
I don't really belive that wanting usable data out of flow sampling
(which necessarily due to the nature of sampling cannot do reassembly),
or the ability to assign queues to traffic on the basis of something
other than source/dest address and an empty flow label result in what
would be characterized as flawed middlebox design. Nor whould I
characterize the devices that do this as firewalls, elsewise every
high-scale router on the internet is a firewall.
Would the draft be more acceptable if we stated this as the motivation and
removed references to NAT64?
Ron
-----Original Message-----
From: Ole Troan [mailto:[email protected]]
Sent: Wednesday, February 06, 2013 4:51 PM
To: Ronald Bonica
Cc: Fernando Gont; [email protected]; [email protected]
Subject: Re: Moving forward draft-ietf-6man-oversized-header chain?
while we are on the topic, and you made me re-read the document.
section 4:
issues with terminology. call a device that walks the extension header
chain something else than a router.
rfc2460 definition of a router; "extension headers are not examined or
processed by any node along a packet's delivery path".
a switch in my book doesn't look at L3 headers.
use "middlebox" or "filtering router"?
section 3:
is the main justification for this work to make NAT64s function better?
if so that might be a little short-sighted, by the time we've updated
IPv6 implementations... perhaps use a different example than NAT64?
section 5:
restricting the header chain seems like an incomplete solution. doesn't
a middlebox need to reassembly fragments anyway, to deal with mis-
ordered fragments?
at least at some point I thought BSD sent fragmented packets by sending
the last fragment first.
with a more idealist hat on:
that extension headers are hard to parse, some consider a feature of
IPv6.
a feature that tries to protect the end to end Internet, i.e. that we
can deploy new transport protocols and extension headers without
upgrading all intermediate boxes. changing the IPv6 protocol for a
flawed design (aka middleboxes), is that wise?
might as well just deprecate IP fragmentation. (which I would be in
favour of).
and don't get me wrong, I can't imagine any use case for an extension
header chain longer than 1280 bytes either.
cheers,
Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
