Subject: [secdir] secdir review of draft-templin-intarea-seal

From: "David Harrington" <[email-masked]>
Date: Tue, 19 Feb 2013 18:27:36 -0500

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
[email-masked]
+1-603-828-1401

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 19 Feb 2013 16:31:19 -0800 (PST)

Hi Dan,

Thank your for looking over the document and sending these useful comments.
Please see below for responses:

Regards - Fred
[email-masked]

----- Original Message -----
> From: David Harrington <[email-masked]>
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Sent: Tuesday, February 19, 2013 3:27 PM
> Subject: secdir review of draft-templin-intarea-seal
> 
> Hi,
> 

OK.

> supposed to be deployed, this may not be an issue.

The RFC5320 version of SEAL was never meant to be deployed outside of
simple test networks. Hence, implementations of RFC5320 and implementations
of this new spec will not show up on the same network.

> issues). It does still provide for MTU consistency, segmentation, etc., but

Yes, these fields are maintained as optional in case SEAL were to be deployed
on some network that provides alternate means of security (e.g., a corporate
enterprise network that is cordoned off from the Internet with security gateways,
firewalls, etc.

> be enough, but the discussion is very short.

The only implication I am aware of is that the ITE may end up using more
conservative values for these constants than necessary for most of the paths
from the ITE to the ETE. And, the document already states that:

  "The ITE may instead maintain the packet sizing variables and constants as per ETE
   (rather than per SEAL path) values. In that case, the values reflect the lowest-common-
   denominator size across all of the SEAL paths associated with this ETE."

Does this look like enough?

> not. Of course, this document is only informational, so normative might not

You have touched on an interesting point. The UDP checksum drafts are currently
still in the publication queue, and I do not know if there is a know date at which
they would be published. So, I have taken the precedent established in the
 publication of LISP (RFC6830) where these drafts were cited as informational-only.

> using these as hints, or not, might impact interoperability.

The SEAL decision process is driven by the ITE, and the ETE passively accepts
and/or evaluates whatever the ITE sends. So, different ITE implementations may
take or not take the recommendations in this sections and still remain interoperable
with any ETE implementations.

> if a recommended default, or a default algorithm for determining window size

The window size is intentionally left unspecified, and left up to implementations.
The choice of window size will not affect interoperability even if multiple
implementations select different window sizes.

> to me, and I wonder if it could be tightened up.

The concern is no different than for the security concerns an ordinary host would
have to observe when it receives an ICMP packet too big message. Most hosts
accept the message unconditionally, but they really should look at the contents
of the message to see whether it corresponds to a packet the host actually sent.
So, I'm not sure whether more could be said about this?

> individual submission rather than experimental. I wanted the Ads to be aware

There have been a number of comments on this. The going consensus now seems
to be that we will still ask for the TCP/UDP user port number allocations, but we will
no longer ask for the IP protocol number assignment.

> Hope this helps.

This review has been very useful, Dan. Thanks again for taking the time!