Hi Tom, > -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: Tuesday, March 10, 2015 5:52 PM > To: Templin, Fred L > Cc: [email protected] > Subject: Re: [Int-area] Fwd: New Version Notification for > draft-herbert-gue-03.txt > > 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!
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. > >> 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. 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. > >> 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. 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 [email protected] > 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
