Subject: [Int-area] Fwd: New Version Notification for draft-herbert-gue-03.txt

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Mar 2015 12:33:55 -0700

Hello,

We have been discussing Generic UDP Encapsulation (GUE) in nvo3, but
since it is intended to be a generic encapsulation and tunneling
protocol I'm posting to int-area also.

Thanks,
Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Fri, Mar 6, 2015 at 2:11 PM
Subject: New Version Notification for draft-herbert-gue-03.txt
To: Tom Herbert <[email-masked]>, Osama Zia <[email-masked]>

A new version of I-D, draft-herbert-gue-03.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:           draft-herbert-gue
Revision:       03
Title:          Generic UDP Encapsulation
Document date:  2015-03-06
Group:          Individual Submission
Pages:          24
URL:            http://www.ietf.org/internet-drafts/draft-herbert-gue-03.txt
Status:         https://datatracker.ietf.org/doc/draft-herbert-gue/
Htmlized:       http://tools.ietf.org/html/draft-herbert-gue-03
Diff:           http://www.ietf.org/rfcdiff?url2=draft-herbert-gue-03

Abstract:
   This specification describes Generic UDP Encapsulation (GUE), which
   is a scheme for using UDP to encapsulate packets of arbitrary IP
   protocols for transport across layer 3 networks. By encapsulating
   packets in UDP, specialized capabilities in networking hardware for
   efficient handling of UDP packets can be leveraged. GUE specifies
   basic encapsulation methods upon which higher level constructs, such
   tunnels and overlay networks for network virtualization, can be
   constructed. GUE is extensible by allowing optional data fields as
   part of the encapsulation, and is generic in that it can encapsulate
   packets of various IP protocols.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Mar 2015 19:53:49 +0000

Hi Tom,

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Monday, March 09, 2015 12:34 PM
> To: [email-masked]
> Subject: [Int-area] Fwd: New Version Notification for draft-herbert-gue-03.txt
> 
> Hello,
> 

It would be nice to explore whether this could be harmonized with the generic
UDP encapsulation specified by AERO. For example, AERO provides the option
to include tunnel fragmentation to take care of MTU issues without causing IP
fragmentation. I understand your work has also investigated integrity issues,
which perhaps AERO could benefit from.

Thanks - Fred
[email-masked]

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Mar 2015 17:18:19 -0700

> which perhaps AERO could benefit from.

Hi Fred,

I have been thinking about this. It seems very plausible that GUE
could be used as an AERO compatible encapsulation mechanism.

Looking at the AERO header in draft-templin-aerolink-52.txt section
3.10, the primary header is very close to GUE (flag-fields, encap of
IP protocol). Checksum field in AERO is similar to GUE header checksum
(draft-herbert-guecsum-00). I think the Signature field might be an
instance of security field in GUE
(draft-hy-gue-4-secure-transport-00), although I'm not as certain-- do
you have more detail as to what goes in this field?

The fragmentation fields in AERO are interesting. If my reading is
correct this is implementing fragmentation as part of the
encapsulation in order avoid the path MTU problems associated with
tunnels. I think this could be added to GUE as another option,
probably 1 bit flag referring to a 64 bit header. I'll try to take a
stab at defining this for GUE.

Thanks,
Tom

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Mar 2015 15:34:48 +0000

Hi Tom,

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Monday, March 09, 2015 5:18 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [Int-area] Fwd: New Version Notification for draft-herbert-gue-03.txt
> 

AERO as a user of GUE encapsulation would be a reasonable synergy. I have
a UDP port number for AERO (8060) that we could apply also to GUE.

> (draft-herbert-guecsum-00).

Actually, I just recently put the header checksum in as a placeholder until
the UDP encaps checksum discussions conclude - at which point, I suspect
the checksum considerations would be the same as for GUE.

> I think the Signature field might be an

Again, the signature field was added as a placeholder. What I am looking
for is a cryptographic signature over the packet that can be used for data
origin authentication when the source is in an untrusted network like the
Internet. But, the signature algorithms are currently unspecified. Is this
something that would be satisfied by GUE?

> stab at defining this for GUE.

Andy Malis and his co-authors first described "tunnel fragmentation" in
Section 3.1.7 of RFC2764. What AERO is describing is precisely that, except
that AERO has all of the details worked out.

Thanks - Fred

---

From: Tom Herbert <[email-masked]>
Date: Tue, 10 Mar 2015 17:51:55 -0700

> a UDP port number for AERO (8060) that we could apply also to GUE.
Great! What a coincidence, GUE was assigned 6080!

Are there tunnel semantics for AERO above the encapsulation then?

> something that would be satisfied by GUE?
In GUE, the security field is more to provide integrity and
authentication of the GUE header. For authenticating the whole packet
we'd probably use IPsec which works out pretty nicely since we're
already encapsulating by IP protocol. The GUE security field is 64,
128, or 256 bits in size and the security cookies has at least been
implemented I believe.

> that AERO has all of the details worked out.
Thanks for the pointer. It does seem reasonable to support this in GUE.

Thanks,
Tom

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Mar 2015 16:01:42 +0000

Hi Tom,

> Sent: Tuesday, March 10, 2015 5:52 PM
> To: Templin, Fred L
> Cc: [email-masked]

I have noted many other coincidental numbering assignments in the past
also; as if someone in the number assignment business has a draconian
sense of humor.

> Are there tunnel semantics for AERO above the encapsulation then?

AERO uses IPv6 ND and DHCPv6 messaging above the encapsulation layer;
it can therefore work over any encapsulation format, with the exception
that it expects the encapsulation to include a fragmentation and reassembly
capability.

> 128, or 256 bits in size and the security cookies has at least been

What AERO is looking for is data origin authentication. What I was
anticipating was a signature over the entire packet so that middle
boxes cannot rewrite the data. It would be something like an
"IPsec-lite" without actually having to invoke IPsec, IKE and the
like. But, I don't mind having my mind changed by a security analysis
that would say what I want is no better than IPsec.

> Thanks for the pointer. It does seem reasonable to support this in GUE.

I can assure you that the devil is in the details. If we are to work this, then
let's work it together.

Thanks - Fred