On Tue, Mar 10, 2015 at 8:34 AM, Templin, Fred L <[email protected]> wrote: > Hi Tom, > >> -----Original Message----- >> From: Tom Herbert [mailto:[email protected]] >> Sent: Monday, March 09, 2015 5:18 PM >> To: Templin, Fred L >> Cc: [email protected] >> Subject: Re: [Int-area] Fwd: New Version Notification for >> draft-herbert-gue-03.txt >> >> On Mon, Mar 9, 2015 at 12:53 PM, Templin, Fred L >> <[email protected]> wrote: >> > Hi Tom, >> > >> >> -----Original Message----- >> >> From: Int-area [mailto:[email protected]] On Behalf Of Tom Herbert >> >> Sent: Monday, March 09, 2015 12:34 PM >> >> To: [email protected] >> >> Subject: [Int-area] Fwd: New Version Notification for >> >> draft-herbert-gue-03.txt >> >> >> >> 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. >> > >> > 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. >> > >> >> Hi Fred, >> >> I have been thinking about this. It seems very plausible that GUE >> could be used as an AERO compatible encapsulation mechanism. > > 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. > Great! What a coincidence, GUE was assigned 6080!
Are there tunnel semantics for AERO above the encapsulation then? >> 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). > > 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 >> 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? > > 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? > 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. >> 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. > > 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 for the pointer. It does seem reasonable to support this in GUE. Thanks, Tom > Thanks - Fred > [email protected] > >> Thanks, >> Tom >> >> >> >> >> >> > Thanks - Fred >> > [email protected] >> > >> >> Thanks, >> >> Tom >> >> >> >> >> >> >> >> ---------- Forwarded message ---------- >> >> From: <[email protected]> >> >> Date: Fri, Mar 6, 2015 at 2:11 PM >> >> Subject: New Version Notification for draft-herbert-gue-03.txt >> >> To: Tom Herbert <[email protected]>, Osama Zia <[email protected]> >> >> >> >> >> >> >> >> 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 >> >> >> >> _______________________________________________ >> >> Int-area mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
