.de Sc
\\s-1\\$1\\s0\\$2
..
.ds cA 2004/426
.ds aR \s-1PSARC\s0
.LP
.so ../../amac
.Co
.ds LF \fI\*(aR/\*(cA\fP
.ds RF \fICopyright 200r Sun Microsystems, Inc.\fP
.if n .ds CF
.IP \fBSubject:\fP 15
Checksum Support for Snoop
.IP "\fBSubmitted by:\fP" 15
Philip Kirk
.IP \fBFile:\fP 15
\*(aR/\*(cA/opinion.ms
.IP \fBDate:\fP 15
June 9th, 2004
.IP "\fBCommittee:\fP" 15
James Carlson,
Ralph Campbell,
Bill Sommerfeld,
Gary Winiger.
.IP "\fBProduct Approval Committee:\fP" 15
Solaris PAC
.br
solaris-pac-opinion@sun.com
.pn 2
.NH
Summary
.LP
This project adds TCP/IP checksum validation to snoop, so that
administrators can more easily understand why packets are dropped, and
to achieve better functional parity with open source equivalents.
.NH
Decision & Precedence Information
.LP
The project is approved as specified in reference [1].
.LP
The project may be delivered in a minor release of Solaris.
.NH
Interfaces
.LP
The project exports the following interfaces.
.if n .ne 8
.if t .ne 3
.TS H
box;
c s s
l | l | l.
Interfaces Exported
_
Interface	Classification	Comments
_
.TH
output text	Unstable	T{
Add ERR summary and verbose text
T}
.TE
.LP
The project imports the following interfaces.
.if n .ne 8
.if t .ne 3
.TS H
box;
c s s
l | l | l.
Interfaces Imported
_
Interface	Classification	Comments
_
.TH
sys/pattr.h	Consolidation Private	PSARC 2003/264
.TE
.NH
Opinion
.LP
Although this project does represent a step forward for snoop, and the
proposal is complete, it highlights a problem area in the existing
architecture.  Several ARC members felt that it was important to have
these issues addressed in a more complete manner.  This case was
derailed in order to provide the PAC with advice in that direction.
.LP
The issue is that when hardware checksum offloading (PSARC 2003/264)
is used, IP's outbound packets do not have valid checksums.  Because
snoop and other monitoring (tcpdump) and raw packet (bpf, Packet
Shell) applications receive packets via interfaces at the DLPI level,
this means that they have several significant flaws.
.NH 2
Bad Checksums Exposed To Users
.LP
The first and most obvious issue is that packets with bad checksums
are exposed to users.  This often leads to confusion and, potentially,
to outright application failure.
.NH 2
No Means To Detect Problem
.LP
If other applications were designed to handle the bad checksum
problem, they'd be faced with a separate problem in the design of
hardware checksum offload: there is no way for a raw listener to find
out if any other streams have hardware checksum enabled.  At best,
they can query if the device supports hardware checksum and, if it
does, merely assume that all DLPI users that speak IP use the feature
and that checksums are thus not reliable, as this project proposes
doing for snoop.
.NH 2
Cannot Discriminate Input From Output
.LP
The raw DLPI interfaces do not distinguish input from output.  This
means that if an application can detect the potential issue as above,
it cannot necessarily determine which packets are affected.  As the
lack of input/output indication is a serious independent flaw in
snoop's design, especially on non-Ethernet media, this is an issue
that should be addressed separately.
.NH 2
Local Versus Forwarded Traffic
.LP
If the application knew when hardware checksum was in use, and which
packets were transmitted by IP, we would find that monitoring IP
forwarding becomes a problem, as forwarded packets already have the
correct checksums and must not be touched by hardware.  Unfortunately,
there is no way to know which these are among the transmitted packets.
.NH 2
Snoop File Format Cannot Accommodate Data
.LP
The snoop file format cannot accommodate flags or other information
about the data source.  This means that even if the above measures can
be used to mitigate the problem, saved snoop packet traces are still
vulnerable to interpretation errors.
.NH 2
Inconsistent Overall Architecture
.LP
Similar issues are present with IPsec acceleration, where the raw
(unencrypted) data would ordinarily be seen by the snoop user rather
than the encrypted data that are sent on the wire.  To prevent this
exposure, we turn off hardware IPsec acceleration when other DLPI
listeners are present.  Essentially the same issue is present for
hardware checksum offload, but the solution is not the same.
.NH
Minority Opinion(s)
.LP
None
.NH
Advisory Information
.LP
The PAC is advised to fund an effort to resolve the observability and
DLPI functional problems caused by hardware checksum offloading.
.NH
Appendices
.NH 2
Appendix A: Technical Changes Required
.LP
None
.NH 2
Appendix B: Technical Changes Advised
.LP
None
.NH 2
Appendix C: Reference Material
.LP
Unless stated otherwise, path names are relative to the case
directory \*(aR/\*(cA.
.IP 1.
Specification
.br
File:
spec.txt