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

"Fred L. Templin" <> Wed, 20 February 2013 00:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B426C21F8878 for <>; Tue, 19 Feb 2013 16:31:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vzOOQKIMgIQc for <>; Tue, 19 Feb 2013 16:31:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0CA2A21F87FF for <>; Tue, 19 Feb 2013 16:31:21 -0800 (PST)
Received: from [] by with NNFMP; 20 Feb 2013 00:31:21 -0000
Received: from [] by with NNFMP; 20 Feb 2013 00:31:21 -0000
Received: from [] by with NNFMP; 20 Feb 2013 00:31:21 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 45606 invoked by uid 60001); 20 Feb 2013 00:31:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1361320280; bh=287KGpQIlnoPCKHfYGl/apT+CIhC0QLSNU5tSYqJTiY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eVh1m+h0FFntsR+WQDkN+tq5WVhTq8Zm4PTa2aka3HFHTxWcaCHqOjCukZtYaICw5RgxhlnXxzLkfbrgvpfalJj3/x/t4eYWUAHjHZOzFMPPMszRnzYJjqVhcRpjpOcESfoI9Hr1RJ/+SWMlQtBpZarNVLzuuoYORR93GjFdEYk=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5yoJBcaXvxIAdOE2T2MteonzgcDuwcZfvyQamp5OhFBKU9OIOihZYine0WBavg5XBXO1Uz1ihy0ldjq71KX4Lp8Lk4MBRZmoSzXmaksED61TDQLIyFP4gxtC185E+Ry7U9UtUJPuEtqq8OtFFCR/3a0fEpzzMa1PfSZERo+dZFs=;
X-YMail-OSG: chik7SoVM1mq3X_kJ9jQOBDRzNHT2NoLsBHqpg.V2qh_sHM BPgKYcNIougTbCJsZfsYwP2UN9dHkDKYqpiblLH62ca63MgwU42rWwjRZMBm .0xcP8yGcI9GY.NQwn5L0FQwMBAdHwm3NjuhDLFC7xIaJ27QSDRqe.zI.B5X Cv6TQYcs1OWP6XiZ7UrkC_xxQFRstKlswG1uxZU8E9yrgZNhlZdMFLMpYGnr .WnAAU3tyMbRhR_15slQU4YZ64U1gBZn7P1XPTv.1hwDgT4qXZYCCtDRaE9T SKzROUpVW.klZZkKIldVMZjz1Bo49C6zk9Uob0gClQmyYEHIwFottQodcZG6 3VkUnLISs3HwK3G74zt8fGhKuUSny2RJW8bvUMG34p8gTD1fUCNhmneqaJ28 GlLG_Jj2EMJD.WGkgU2S2uB_R89jYL_7mNn3ypMbvJxXZfxV8EQrJqX.XDVh axsqIB6YtBJltZvaa8SYZSK6q0unY89irxNdmKnAPs5pNsDaaMM2j8DVapld ePBInCfiG0Zw0IBM-
Received: from [] by via HTTP; Tue, 19 Feb 2013 16:31:19 PST
X-Rocket-MIMEInfo: 001.001, SGkgRGFuLAoKVGhhbmsgeW91ciBmb3IgbG9va2luZyBvdmVyIHRoZSBkb2N1bWVudCBhbmQgc2VuZGluZyB0aGVzZSB1c2VmdWwgY29tbWVudHMuClBsZWFzZSBzZWUgYmVsb3cgZm9yIHJlc3BvbnNlczoKClJlZ2FyZHMgLSBGcmVkCmZsdGVtcGxpbkBhY20ub3JnCgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBEYXZpZCBIYXJyaW5ndG9uIDxkYmhhcnJpbmd0b25AY29tY2FzdC5uZXQ.Cj4gVG86IGRyYWZ0LXRlbXBsaW4taW50YXJlYS1zZWFsQHRvb2xzLmlldGYub3JnOyBpZXNnQGkBMAEBAQE-
X-RocketYMMF: fltemplin
X-Mailer: YahooMailWebService/
References: <00cb01ce0ef8$b3cc6c00$1b654400$>
Message-ID: <>
Date: Tue, 19 Feb 2013 16:31:19 -0800
From: "Fred L. Templin" <>
To: David Harrington <>, "" <>, "" <>
In-Reply-To: <00cb01ce0ef8$b3cc6c00$1b654400$>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 19 Feb 2013 16:35:08 -0800
Cc: "" <>
Subject: Re: [secdir] secdir review of draft-templin-intarea-seal
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "Fred L. Templin" <>
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Feb 2013 00:31:23 -0000

Hi Dan,

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

Regards - Fred

----- Original Message -----
> From: David Harrington <>
> To:;
> Cc:
> Sent: Tuesday, February 19, 2013 3:27 PM
> Subject: secdir review of draft-templin-intarea-seal
> 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.

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.

> 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.

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.

> 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.

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?

> 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.

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.

> 5) section 5.4.7 suggests taking some ICMP messages as "hints". I 
> wonder if
> 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.

> 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.

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.

> 7) In, 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.

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?

> 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.

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!

> David Harrington
> +1-603-828-1401