On 08/10/2012 09:07, [email protected] wrote:
Thanks for your comments, see below.
Gorry
Stewart Bryant has entered the following ballot position for
draft-ietf-6man-udpzero-06: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
This discuss applies to both this draft and
draft-ietf-6man-udpchecksums-04
Fundamentally I support the liberalization of the position regarding IPv6
UDP checksums when UDP is used for tunnels and hope to get to a yes
position on both drafts. However, there is some text that needs
discussion, and then we need to discuss the consequences of that
discussion. The rational for the slightly conservative position taken in
the case of tunnels seems to based on the following text:
"IP packets may be corrupted as they traverse an Internet path.
Evidence has been presented [Sigcomm2000] to show that this was once
an issue with IPv4 routers, and occasional corruption could result
from bad internal router processing in routers or hosts. These
errors are not detected by the strong frame checksums employed at the
link-layer [RFC3819]. There is no current evidence that such cases
are rare in the modern Internet, nor that they may not be applicable
to IPv6. It therefore seems prudent not to relax this constraint.
The emergence of low-end IPv6 routers and the proposed use of NAT
with IPv6 further motivate the need to protect from this type of
error."
However we do have a body of evidence that is not discussed in the
document. Firstly we have a decade of experience with MPLS VPNs where the
VPN Identifier label, which is used to steer the traffic to a particular
customer network (i.e. is functionally equivalent to an address), is not
protected by a checksum. I am not aware of any concerns expressed by
operators in this regard, and I am not aware of any work in the MPLS WG
to introduce checksum like protection.
1) I'm not sure whether you are saying MPLS is robust to these effects
*OR* that MPLS stacks have monitored for this case, e.g. do log such an
unexpected VPN Identifier label, and somehow report this (and hence there
is evidence that MPLS routers do not see such errors)
MPLS is not robust against this. If it gets a packet with a valid DL CRC
and it finds the VPNid in the label table, the packet gets delivered
without further ado. However if it gets delivered to the wrong customer
then that is a security violation, and that does not seem to be an
issue expressed by the operator or user community, and thus I conclude
that the occurrence is not significant.
It's implementation specific, but I am fairly sure that unknown VPNid will
be counted in most implementations.
We also have a decade of experience with pseudowires. With one exception
that we will discuss in a minute, none of the PW designs have any form of
data integrity protection other than the CRC imposed by the network
datalink at each hop. In the specific case of the Ethernet PW, there are
two modes: one in which the CRC is stripped at ingress to the PW and
recalculated at egress, and another where it is preserved end to end.
There is very little, if any, deployment of the end to end CRC
preservation mode. Given that there must be some low level of corruption
of the frames, I would conclude that the protocols that are likely to be
tunneled are sufficiently hardened that the occasional corruption is of
no practical consequence.
2) On acceptability of residual corruption: I think I missed something -
If you are saying that using Ethernet "bridging" is safe at L2, then
that's not this discussion. I am interested in any experience that would
help in understanding the impact of no checksum for IPv6, e.g. experience
in how often the IPv4 checksum and IPv4/UDP checksum fail.
To be clear I am only considering the tunneling case not the general case,
and note that with the most frequently used tunneling protocol (MPLS)
it is unprotected and this does not seem to be causing any issue.
3) On practical rate of residual corruption: Is there experience of using
MPLS/PWE across low-end and legacy routers? I am not aware of this, but I
would be really interested in knowing more about the reliability across an
end-to-end path i.e. PWE and MPLS through home gateways, firewalls,
load-balancers, NAT and NAPT. What experience has the community seen?
People are looking at low end with a view to pushing MPLS out to
closer to the edge of the network, but the concern is with label
security rather than label corruption. However there is not much
experience with low end boxes.
Thus I would conclude that the level of corruption is sufficiently rare
and of sufficiently minor consequence that at least in the case of
service provider networks implementing UDP tunneling, it is safe to omit
the UDP checksum without analysis of the application.
4) I disagree.
I would assume so. I suspect because we are looking at different
aspect of the problem.
I would propose that the text should include some acknowledgement of this
recent body of evidence and that the recommendation be aligned in
consequence to unconditionally allow C/S free tunneling, at least within
a well managed domain without additional consideration.
5) It seems OK to note the new evidence for use within a well-managed
domain, can you supply references to the usage and experience? I have a
question: would the domain include host stacks and end-to-end usage or
just carrier usage?
The experience we have is with carrier usage, and we only have (strong)
negative evidence. People rarely write reports saying that a system works
well (as expected).
Section 5.1 seems to be duplicated in the two drafts. It would be better
if the text were just in one RFC and the other pointed to it.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
You also note that an application may rely on the checksum to protect it
against packets that may damage it. I find this very weak argument, since
such an application would be vulnerable to packets deliberately malformed
by an attacker, or malformed by a software bug in a peer. The correct
approach is surely to harden the application, and thus the checksum
argument is not persuasive.
6) I'm surprised/misunderstood - many deployed uses of the UDP transport
have relied on the UDP cksum (more latterly this not been the advice of
the IETF, but hard to enforce). Is this suggesting the IETF actually
declare these (existing deployed IPv4) apps as unsuitable for use with
IPv6 over the general Internet. That's NOT something I would personally
like to do, have I understood correctly?
No, but your argument is non-the-less weak. If the only thing holding
the app from melting is the UDP c/s, then it really needs some
security hardening.
You note the need to signal the agreement not to use c/s, I think that
you need to include the configuration of this property as an alternative,
and note that configuration may be implicit in the definition of the UDP
payload.
7) The intent was not to change the semantic of the cksum for apps that
expected the original behaviour. If you have an app that is willing to use
no cksum - such as the tunnels - this may be fine, then I see two
possibilities: It works (e.g. within a carrier network) or it may fail
(e.g. via a NAPT/firewall that recalculates a cksum). I think it would be
"nice" for the "app" to know it has UDP connectivity, but no UDP zero
cksum connectivity - i.e. not just break when a route changes or a user
moves to a new network. What do you suggest apps should do?
By definition an app does not know that it is being tunneled.
If the app wants to set the c/s in the UDP header that it requests from
the host stack, that is something that I actively support. However
the path over the network once it leaves that stack (including
tunneling in the host itself) is not something that it should know
or care about.
- Stewart
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
