Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.

--
This document is an individual submission in the INT area, and obsoletes
RFC5320, which was published as Experimental in the ISE stream.
RC5320 contains an IESG Note, saying the decision to publish is not based on
IETF review for things like security.
This document is being published as Informational, not Standards-track.
I do not consider my security review as thorough as a standards-track doc
might deserve.

SEAL is the Subnetwork Encapsulation and Adaptation Layer.
It is a layer between the (IP and transport headers) and the content being
sent (so it is between the Transport layer and the Application layer).
Its goal is to provide a virtual topology overlay using content
encapsulation between a point in the network that serves as a SEAL ingress
point and another point in the tunnel that serves as a Seal egress point,
over a multiple-hop physical or virtual network topology. The SEAL protocol
addresses issues relating to MTU consistency, detection of duplicate packets
and packet reordering, segment-to-segment data origin authentication,
segment-to-segment packet header integrity and anti-replay. 
The document also defines a control message protocol that addresses issues
with use of ICMP, where ICMP might be impacted by middleboxes, among other
things.
These specifications are meant to supplement IP's end-to-end message
integrity checking, authentication and confidentiality.

The document appears well-written, clear, and unambiguous.
The security considerations section is short (only 4 paragraphs) but
describes what security issues SEAL is meant to address, and which issues it
is not meant to address.
The Security Considerations section discusses some possible attacks and ways
to mitigate them.
The security features of SEAL are discussed throughout the document.
I feel the security considerations section is reasonable.

I have a few concerns, most not related to security, and the Security Ads
can decide whether they feel these are important to address:
1) The document defines what is effectively SEALv2 to obsolete the SEALv1
defined in RFC5320. SEALv1 had no version field; SEALv2 adds a version
field. It is unclear to me whether there are issues of deploying
implementations of both versions in the same network. The two versions have
significant differences, described in section 1.3, which show these are
quite different protocols, not just a minor evolution. Since v1 was never
supposed to be deployed, this may not be an issue.
2) The identification and Integrity check fields are optional (section 5.3),
and without these fields SEAL doesn't seem to address important security
issues). It does still provide for MTU consistency, segmentation, etc., but
not security.
3) in 5.4.3, it states that the ITE (ingress point) may maintain packet
sizing variables per ETE (egress point), rather than per SEAL path. It
doesn't discuss in detail the implications of this decision, nor how it
might impact interoperability or performance. The existing discussion might
be enough, but the discussion is very short.
4) There are a couple places where IDs are referenced, and it is unclear
whether it should be normative or informative, and what effect the
completion of the ID would have on the SEAL protocol. The most notable for
me was section 5.4.5, which references draft-ietf-6man-udpzero. This
document says set the checksum to 0, and points to the draft for additional
considerations. It is unclear whether SEAL implementations are expected to
change when udpzero gets published or not. This might impact
interoperability, if some set the checksum to 0 and other implementations do
not. Of course, this document is only informational, so normative might not
be important.
5) section 5.4.7 suggests taking some ICMP messages as "hints". I wonder if
using these as hints, or not, might impact interoperability.
6) In 5.5.4, there is mention of the window of acceptable values. I wonder
if a recommended default, or a default algorithm for determining window size
is appropriate.
7) In 5.6.2.1, an ITE should "only process the message if it is able to
recognize the packet as one it had previously set." This seems a bit loose
to me, and I wonder if it could be tightened up.
8) The IANA Considerations requests IANA to assign a user port and an IP
protocol number. RFC5320 used experimental values from ranges defined in
RFC3692 and RFC4727, for experimentation only, and not to be used in any
deployments or shipped products. Having IANA assign values is a significant
change, presumably appropriate since this is being published as an
individual submission rather than experimental. I wanted the Ads to be aware
of this change.

Hope this helps.
David Harrington
ietfdbh at comcast.net
+1-603-828-1401