The Subnetwork Encapsulation and Adaptation Layer (SEAL)
draft-templin-intarea-seal-68

[Ballot discuss]
While I believe there is some value in publishing this specification, I agree with Brian:

    If the author insists on maintaining the Informational status,
  I would suggest a title change to indicate that this is description
  of Boeing-developed protocol.  Otherwise, I suggest moving it
  Experimental like the RFC it is obsoleting.

Existing examples: RFC 3176, RFC 3954, RFC 6812

[Ballot discuss]
While I believe there is some value in publishing this specification, I agree with Brian:

    If the author insists on maintaining the Informational status, I would
  suggest a title change to indicate that this is description of Boeing-developed
  protocol.  Otherwise, I suggest moving it Experimental like the RFC it is
  obsoleting.

Existing examples: RFC 3176, RFC 3954, RFC 6812

[Ballot comment]
I agree with the DISCUSS positions. I'm willing to have the DISUCSSion, but at the end of the day I think we need to say "No thanks" to having this in the IETF stream. The fact is that there is no indication of any consensus in the IETF to move forward with this experimentally; there is no indication that anyone will participate in the experiment. It sounds to me like this work needs to garner a constituency, and it sounds like we would have to figure out where it fits with other protocols (i.e., if it's competing with the or complementary to them). That requires a BOF, not an IETF Last Call and IESG Evaluation. I don't think we should be in the business of publishing things in the IETF stream *in order to* garner interest.

It sounds from other comments like this is interesting work. It seems a shame not to have the IETF do work on this. But until there is demonstrated interest, I don't think this belongs in the IETF stream. Having the ISE publish as Experimental again seems reasonable, and I don't think that the fact the this potentially competes with LISP should preclude that.

[Ballot discuss]
This is a discuss for discussion with the IESG. I anticipate clearing on the call.

I agree with the other IESG review comments and support Brian's discuss.

I addition, this work seems to have a lot of overlap with LISP which is an IETG WG project. I think that the least it should do is to discuss LISP, but I am wondering whether the IESG should consider this as an end-run of IETF work.

[Ballot comment]
I agree with Brian's Discuss.

If this is Informational then it needs to be shaped as a description of a particular company's protocol. It would then be published to allow others to implement and interoperate if they want. If this moves to Experimental (which seems better to me) it should describe the parameters of the experiment.

[Ballot discuss]
I have no objections to the *concepts* developed in this draft, but I have a major concern with the way it is specified. So color me as wanting to discuss the following issues:

1) At this point, I believe it is not in the best interest of the Internet at-large to allocate an IP protocol number to what appears to be an experimental mechanism used only within the confines of a single enterprise.  The author has made many attempts to drum up support for this concept over the years, but it is apparent that vendors are not interested in building this technology into their products.  The current implementation leverages one of the experimental IP protocol numbers available for such use.

2) If the author insists on maintaining the Informational status, I would suggest a title change to indicate that this is description of Boeing-developed protocol.  Otherwise, I suggest moving it Experimental like the RFC it is obsoleting.

[Ballot comment]
1) I agree with Stephen's points on the lack of clarity around the security mechanisms described in this draft.

2) Some of the ICMP processing approaches are good advice for protocol stack developers & operators and could be broken out of this document and published as recommendations for vanilla ICMP.

[Ballot discuss]

I read this fairly quickly so I may have gotten some of
this wrong, in which case, apologies;-)

(1) I don't see anywhere that the ICV algorithm is
defined, nor where any automated key management is
discussed, and I think the AKM is needed given the 32 bit
ICV. What am I missing? I think that needs to be fixed and
is simple to fix properly by selecting an HMAC-SHA-x at
some reasonable length (96 bits) and maybe picking either
TLS or IPsec as being needed for setting up ITE/ETE
security associations, but with a 96 bit ICV you're
probably ok for an informational/experimental draft
without AKM.  To be honest, that lack sends me a big
signal that this isn't ready even after 51 revisions if it
doesn't include those are by now pretty basic things.

(2) Should we really burn an IP protocol number on this?
I've no strong opinion but they are >50% gone and this
seems tenuous and I'm not even sure the IP protocol number
is really needed if TCP and UDP can be used as outer
encapsulations. I'll readily clear this though if someone
explains to me that this draft is par for the course in
terms of getting an IP protocol number.

[Ballot comment]

- Informational obsoleting experimental RFC eh. Works for
me;-) But I'm puzzled its not experimental. Does that
relate to the last call duration? That could be a concern,
given that this wasn't afaik dicsussed on a list.

- 51 revisions, wow.

- p10, the data origin authentication service does not
cover all the payload data so I think calling it that is
misleading. Truth in advertising would suggest calling it
32-bit-weak-128-byte-header-data-origin-authentication or
something.

- p11, savi is only chartered to deal with LANs which
seems very different from what's called a subnetwork here
or for protection of an ITE against source spoofing. I
think the reference is inappropriate as it stands.

- p13, if going to all this trouble, wouldn't an MTU of
more than 1500 be useful to offer as a minimum to the
outside world?

- p13, where's the ICV algorithm or key ID?

- p14, I don't get why a max of 32 seal paths to an ETE is
sensible. (I don't need to know, but the document would be
better if this and similar hardcoded numbers were better
explained.)

- p16, how are ICV secrets updated if they're used for too
much data? (A 32 bit MAC has to mean a small limit here.)

- p17, how do intermediate routers on the path send PTB
messages? do all routers need to be SEAL aware? Its also
not clear to me why an ETE would send a PTB when the
packet is clearly not so big that it didn't get to the
ETE.

- p20, I was surprised by the TCP/UDP outer encapsulation,
you probably should introduce that earlier, maybe even in
the abstract. (Wouldn't the TCP handshake and slow start
be an issue if the application is e.g. RTP? And with UDP
encapsulation, how's congestion handled?)

- p21, does SEAL have an IP protocol number? If RFC5320
had no version field and this is incompatible don't you
need to deprecate the use of 5320 with that IP protocol
number? I guess that's ok for this since there's no real
installed base, right? If there were, it wouldn't be ok.

IESG/Authors/WG Chairs:

IANA has reviewed draft-templin-intarea-seal-51.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We have a question about one of the actions requested of IANA in this
document.

We understands that, upon approval of this document, there are two actions which we must complete.

First, in the Service Name and Transport Protocol Port Number Registry located at:

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

a new user port for both tcp and udp is requested.

Question -> should 'The Subnetwork Encapsulation and Adaptation Layer'
be the description for the user port 'seal'?

Note: We have initiated a request and sent this to the designated expert
for review according to RFC6335 as stated in section 8.1.1:

"IANA MAY accept early assignment [RFC4020 ] requests (known as "early allocation" therein) from IETF working groups that reference a sufficiently stable Internet-Draft instead of a published Standards-Track RFC."

Second, in the Assigned Internet Protocol Numbers registry located at:

http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml

a new protocol number is requested.

Question -> what are the keyword and protocol name to be assigned to the new protocol number?

We understand that these two actions are the only ones required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Subnetwork Encapsulation and Adaptation Layer (SEAL)) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'The Subnetwork Encapsulation and Adaptation Layer (SEAL)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  For the purpose of this document, a subnetwork is defined as a
  virtual topology configured over a connected IP network routing
  region and bounded by encapsulating border nodes.  These virtual
  topologies are manifested by tunnels that may span multiple IP and/or
  sub-IP layer forwarding hops, where they may incur packet
  duplication, packet reordering, source address spoofing and traversal
  of links with diverse Maximum Transmission Units (MTUs).  This
  document specifies a Subnetwork Encapsulation and Adaptation Layer
  (SEAL) that addresses these issues.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-templin-intarea-seal/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-templin-intarea-seal/ballot/


No IPR declarations have been submitted directly on this I-D.

The following is my document write-up for draft-templin-intarea-seal,
in my role as document shepherd.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

    Informational

Why is this the proper type of RFC?

    This document updates the Experimental RFC 5320: The Subnetwork
    Encapsulation and Adaptation Layer (SEAL)

    The described mecchanism is more mature and no longer intended as
    experimental, but is not being proposed as standards-track.

Is this type of RFC indicated in the title page header?

  Yes.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approvedes
documents. The approval announcement contains the following sections:

Technical Summary:

SEAL is a tunnel mechanism that includes ingress encapsulation, egress
decapsulation, and signalling between the ingress and egress. It
overcomes the limitations of implementing tunnels using IP headers
alone by introducing an adaptation layer with features to address
fragmentation/reassembly, source address spoofing, and path MTU
issues.

Working Group Summary:

Was the document considered in any WG, and if so, why was it not
adopted as a work item there?

The original SEAL RFC 5320 came out in Feb 2010.

This update is AD Sponsored, but was not the product of a WG.

SEAL has been taken to the INTAREA WG for consideration
multiple times, including its previous experimental version,
but there has been insufficient interest to accept this as a
WG item.

I have been tracking this work since its beginnings, and
consider it to be a complete and thorough example of a correct
way to do tunneling. It addresses many of the weaknesses of
existing tunnel mechanisms, while focusing solely on only the
features needed to support tunneling.

Was there controversy about particular points that caused the WG to
not adopt the document?

There seems to be general appreciation for the work, but
a hesitation to either adopt or recognize it as a preferred
solution. I believe this is due to a lack of appreciation for
the significance of its contribution.

At various stages - both in the past version and this
update - the WG interacted and provided constructive feedback
and suggestions for improvement. To my knowledge, all
such suggestions are included and/or addressed sufficiently.

Document Quality:

Are there existing implementations of the protocol?

A pre-RFC5320 implementation is available here:

  http://isatap.com/seal

There is no implementation of the currently proposed version
that this document describes.

Have a significant number of vendors indicated their plan to implement the specification?

There is no current implementation, and no plans for vendor
implementations has been presented or discussed.

Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?

I have provided substantial feedback on this document, notably
on the relationship of SEAL reassembly IDs and IPv4 and IPv6
IDs, which have been addressed. This includes a very thorough
review completed Oct. 1, 2012 of -49 updated with a
"differences from experimental SEAL" discussion. I provided
extensive feedback which was addressed in -50.

Substantial input has been provided by others also listed in
the Acknowledgements section, including Joel Halpern and Brian
Carpenter.

The differences between this version and the previous
Experimental version of RFC 5320 are noted in detail in
Section 1.3.

If there was a MIB Doctor, Media Type or other expert review, what was
its course (briefly)?

Not applicable.

In the case of a Media Type review, on what date was the request
posted?

  Not applicable.

Personnel:

Who is the Document Shepherd?

Joe Touch

Who is the Responsible Area Director?

Ralph Droms

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed this document in its entirety. It is very well
written, and is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I am the only known reviewer to provide feedback on the
document in its entirety. I'm not sure whether that is
sufficient as an AD-sponsored document. I would prefer if at
least one other complete review could be provided, but
appreciate that if the rules to not require it, it's OK to
proceed with this version.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

There are no areas of this document that need such
specialized review.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

I have no concerns regarding this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

Not to my knowledge.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

This document is being submitted indivudally because it was
not adopted as a WG item, as noted above. The reasons,
suggested above, do not represent objections of any WG members
to this work.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Not to my knowledge.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

I have reviewed the id-nits output for -50.
The following issues pass:
    - boilerplate
    - ID guidelines check

There are some warnings that should to be fixed upon final
publication:
    - the "Obsoletes" header line needs to be corrected
    - unused references should be cited or removed
    - RFC 1063 should be replaced with RFC 1191
    - RFC 1146 should be replaced with RFC 6247

There are no errors, 16 warnings, and 2 comments.

The complete output of this id-nits test is appended to this
summary.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None required.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

No such normative references are in this document.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

No such downward normative references are in this document.

(16) Will publication of this document change the status of any
existing RFCs?

Yes; this document is intended to Obsolete RFC 5320.

Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?

Yes.

If the RFCs are not listed in the Abstract and Introduction, explain
why, and point to the part of the document where the relationship of
this document to the other RFCs is discussed. If this information is
not in the document, explain why the WG considers it unnecessary.

  RFC 5320 is listed in the introduction, header, abstract,
and introduction, as expected.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

The IANA Considerations section is consistent with the
document and appropriate.

All requests are from existing registries.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

The document does not request the creation of any new IESG
registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No such reviews or automated checks are applicable.

IANA OK.

IANA has reviewed draft-templin-intarea-seal and has the following
comments:

IANA understands that, upon approval of this document, there are two actions
which IANA must complete.

First, the authors request a port assignment, for TCP, UDP, DCCP, and SCTP,
for SEAL. The authors should submit a template for early allocation and put
the Internet Draft as a reference according to RFC6335 as stated in section
8.1.1:

IANA MAY accept early assignment [RFC4020 ]
requests (known as "early allocation" therein) from IETF working groups that
reference a sufficiently stable Internet-Draft instead of a published
Standards-Track RFC.

Second, in the Assigned Internet Protocol Numbers subregistry located in
the Protocol Numbers registry located at:

http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml

a new Protocol Number will be registered as follows:

Decimal: [ tbd ]
Keyword: SEAL
Protocol: Subnetwork Encapsulation and Adaptation Layer
Reference: [ RFC-to-be ]

IANA understands that these are the only actions required upon approval
of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.