Subject: [manet] SEAL

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 2 Jul 2008 14:19:51 -0700

A few months back, I posted an early-phases announcement of
the SEAL proposal (see below). Since that time, the document
has undergone several revisions based on review input and
implementation experience, and has now coverged to a stable
specification ready for publication:

  http://tools.ietf.org/html/draft-templin-seal-22
  
Additionally, there is now a full Linux implementation of
the -22 draft available for experimentation purposes. The
code is relative to the linux-2.6.26-rc7 kernel and is
available for public download at:

  http://osprey67.com/seal

Building and testing is straightforward, and requires only
2 or more linux-based systems capable of booting 2.6.26-rc7.
A simple readme is also provided to help get started.

SEAL provides a well-behaved 32-bit packet ID that can be
used along with a tagger ID for simple and robust MANET
duplicate packet detection (DPD) in SMF. It also provides
a segmentation and reassembly capability suitable for
operation over MANETs with heterogeneous links. In
particular, SEAL dynamically adapts to the path MTU by
adjusting its segmentation size to "tune out" in-the-network
IPv4 fragmentation. It moreover provides increased packet
delivery ratios and avoids path MTU related black holes
that can occur under traditional approaches. 

SEAL supports both tunnel-mode and transport-mode operation,
and supports both unicast and multicast. It further provides
robust built-in capabilities for defeating off-path attacks.
The current version is integrated with the MANET Virtual
Ethernet (VET) interface abstraction, which is also
implemented as specified in:

  http://tools.ietf.org/html/draft-templin-autoconf-dhcp-14

This supports an IPv6-in-SEAL-in-IPv4 encapsulation format
that provides a number of important advantages over alternate
enapsulations such as IPv6-in-IPv6.

Please take a moment to review the specification and code
and provide comments.

Fred Templin
[email-masked]   

>-----Original Message-----
>From: Templin, Fred L 
>Sent: Thursday, February 28, 2008 8:37 AM
>To: manet; Joe Macker; Ian Chakeres; Joseph Kopena
>Cc: Templin, Fred L
>Subject: RE: [manet] SEAL (was: DPD for IPv4 MANETs)
>
>The SEAL proposal is now specified in an I-D:
>
>  http://www.ietf.org/internet-drafts/draft-templin-seal-03.txt
>
>SEAL provides an extended 32bit ID that supports simplified
>DPD for both multicast and unicast. SEAL also accommodates
>MANETs that contain heterogeneous links with diverse MTUs.
>(It is a shame the list was down for so long that an earlier
>attempt to post this failed.)
>
>Fred
>[email-masked]
>
>>-----Original Message-----
>>From: Templin, Fred L 
>>Sent: Friday, February 01, 2008 1:04 PM
>>To: manet; Joe Macker; Ian Chakeres; Joseph Kopena
>>Subject: [manet] SEAL (was: DPD for IPv4 MANETs)
>>
>>
>>I would like to have just one more word on this subject
>>for now. I would like to propose a new IP encapsulation
>>protocol called the:
>>
>>  "Subnetwork Encapsulation and Adaptation Layer (SEAL)" 
>>
>>protocol which would be used by routers for encapsulating
>>the packets they send across a subnetwork within a MANET.
>>The solution defines a new IP protocol type for SEAL and
>>a new encapsulation format for encapsulating both unicast
>>and multicast IP packets with an IPv4 header and a 4-byte
>>"SEAL header" as the outer encapsulation as follows:
>>
>>                     +---------------------+
>>                     |    Outer IPv4 Hdr   |
>>                     ~      (20 bytes)     ~
>>                     |    (ipproto=SEAL)   |
>>                     +---------------------+
>>                     |  SEAL Hdr (4 bytes) |
>>+-------------+      +---------------------+ 
>>|             |      |                     |
>>|  Original   | ==>  |      Original       |
>>~     IP      ~      ~         IP          ~
>>|   Packet    |      |       Packet        |
>>|             |      |                     |
>>+-------------+      +---------------------+
>>
>>where the SEAL header has the following format:
>>
>> 0                             1 1             2 2             3
>> 0                             5 6             3 4             1
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>|     ID Extension (16 bits)    |  Next Header  |P|R|S|  Seg #  |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>and the fields are defined as follows:
>>
>> ID Extension - a 16-bit extension of the ID field in the outer
>>                IPv4 header; contains the upper 16 bits of a 32
>>                bit id when combined with the outer ID.
>>
>> Next Header  - an 8-bit next header value that is used exactly
>>                as for the IPv6 Next Header and IPv4 Protocol.
>>
>> P            - a 1-bit flag. If P=1, this is a probe packet for
>>                which the decapsulator sends a probe-reply.
>>
>> R            - a 1-bit flag. If R=1, this is a reply to a probe.
>>
>> S            - a 1-bit flag. If S=1, this is part of a segmented
>>                packet using SEAL segmentation
>>
>> Segment #    - a 5-bit segment number. Encodes the segment number
>>                (from 0 - 31) of a segmented SEAL packet.
>>
>>The 16-bit ID in the outer IPv4 header contains the low-order
>>16 bits, and the 16-bit ID extension in the SEAL header 
>>contains the high-order 16 bits of a 32-bit identification
>>included by the encapsulator. The value should be set as
>>monotonically-increasing, i.e., the same as for the IPv6
>>fragment ID. The combined 32-bit value can be used for
>>simplified I-DPD checks for duplicate detection.
>>
>>The SEAL segmentation and reassembly procedure is used
>>only when necessary and entails a simple cutting-and-pasting
>>of the original IP packet when the original IP packet is too
>>large for the subnetwork. The SEAL encapsulator splits a
>>too-large original IP packet into smaller segments for which
>>each segment except the final one is of equal-length. Each
>>segment is encapsulated in an outer IPv4/SEAL header with
>>the S flag set to 1 and and with a Segment number set to 0
>>for the first segment, 1 for the second segment, etc. (there
>>are at most 32 segments in a segmented SEAL packet). The SEAL
>>decapsulator splices a segmented SEAL packet back together
>>simply by splicing segments 0 thru last together in
>>increasing segment number.
>>
>>The 'P' and 'R' flags are used to probe the path MTU on the
>>path to the SEAL decapsulator and are to be used for unicast
>>only (not multicast). The 'P' flag can be set on either
>>actual data packets or on specialized probe packets that 
>>are discarded by the decapsulator. The 'R' flag is set on
>>specialized reply packets that include identifying information
>>that identifies the probe packet that triggered the reply.
>>
>>Finally, the "Next Header" allows multi-protocol operation
>>over SEAL encapsulation. The inner packet could be an IPv4
>>packet, an IPv6 packet, a UDP encapsulation (such as proposed
>>for the LISP protocol) etc.
>>
>>Comments are welcome,
>>
>>Fred
>>[email-masked]
>>_______________________________________________
>>manet mailing list
>>[email-masked]
>>http://www.ietf.org/mailman/listinfo/manet
>>
_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet