Subject: Re: Transmission of IPv6 Jumbograms as Atomic Fragments

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 19 Nov 2021 15:32:05 +0000

Thanks Mark, but I don’t want AH; I want AERO/OMNI. I want the Identifications to serve
the dual purpose of supporting the fragmentation/reassembly process and providing an
in-window value that recipients can use to detect spurious packets. And, I want the same
mechanism used for packets of all sizes, up to and including jumbos.

Fred

From: Mark Smith [mailto:[email-masked]]
Sent: Thursday, November 18, 2021 4:11 PM
To: Templin (US), Fred L <[email-masked]>
Cc: Nick Hilliard <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Transmission of IPv6 Jumbograms as Atomic Fragments

On Fri, 19 Nov 2021, 07:12 Templin (US), Fred L, <[email-masked]<mailto:[email-masked]>> wrote:
Nick,

> Do you have a use case in mind for the ID field?

Thank you for this timely question. I just got done posting a major update to the
draft, which now is titled: "IPv6 Packet Identification" and considers all forms of
IPv6 packets and not just Jumbograms. In answer to your question here is the new
Section 2 text from the draft (link provided below):

"2.  IPv6 Packet Identification

   When IPv6 sources and destinations have some way of maintaining
   "windows" of acceptable Identification values, the destination may be
   able to examine received packet Identifications to determine whether
   they likely originated from the source.

This seems to be describing the sequence number verification used in IPsec AH per RFC 4302.

It may be worth either just using AH as is, and getting all of its other benefits, or look at creating a simplified version of it rather than modifying the jumbogram EH to start duplicating existing AH functionality.

According to RFC 4302 there are a range of reserved SPI values (1 through 255), you could use one of those to indicate a light weight version of AH that just does packet identification, avoiding the need to set up Security Associations with IKE.

Regards,
Mark.

The AERO
   [I-D.templin-6man-aero] and OMNI [I-D.templin-6man-omni]
   specifications discuss methods for maintaining windows of
   unpredictable values that may reduce attack profiles in some
   environments."

Thanks, and here is the draft URL:

https://datatracker.ietf.org/doc/draft-templin-6man-jumbofrag/

Fred

> -----Original Message-----
> From: Nick Hilliard [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: Thursday, November 18, 2021 9:16 AM
> To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
> Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>
> Subject: Re: Transmission of IPv6 Jumbograms as Atomic Fragments
>
>
> Templin (US), Fred L wrote on 18/11/2021 15:23:
> > Bob, what I want is exactly the Identification field that is found in the Fragment Header
> > while simply leaving the rest of the fields of that header set to 0
>
> Do you have a use case in mind for the ID field?
>
> Nick

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Sat, 20 Nov 2021 02:52:46 +1100

> mechanism used for packets of all sizes, up to and including jumbos.

AH + JG

Done. No reinventing wheels.

>
> Fred
>
>
>
> *From:* Mark Smith [mailto:[email-masked]]
> *Sent:* Thursday, November 18, 2021 4:11 PM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* Nick Hilliard <[email-masked]>; IPv6 List <[email-masked]>
> *Subject:* Re: Transmission of IPv6 Jumbograms as Atomic Fragments
>
>
>
> On Fri, 19 Nov 2021, 07:12 Templin (US), Fred L, <
> [email-masked]> wrote:
>
> Nick,
>
> It may be worth either just using AH as is, and getting all of its other
> benefits, or look at creating a simplified version of it rather than
> modifying the jumbogram EH to start duplicating existing AH functionality.
>
>
>
> According to RFC 4302 there are a range of reserved SPI values (1 through
> 255), you could use one of those to indicate a light weight version of AH
> that just does packet identification, avoiding the need to set up Security
> Associations with IKE.
>
>
>
> Regards,
>
> Mark.
>
>
>
> The AERO
> > From: Nick Hilliard [mailto:[email-masked]]
> > Cc: IPv6 List <[email-masked]>
> [email-masked]

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 19 Nov 2021 16:18:06 +0000

I am sorry Mark, but this is not AH – the AERO/OMNI identification mechanism
is modeled after the way TCP peers negotiate sequence number windows, with
the expectation that the peers may renegotiate sequence numbers frequently to
keep the attack surface unpredictable. Please do not make blanket statements
without reading documents.

Fred

From: Mark Smith [mailto:[email-masked]]
Sent: Friday, November 19, 2021 7:53 AM
To: Templin (US), Fred L <[email-masked]>
Cc: Nick Hilliard <[email-masked]>; IPv6 List <[email-masked]>
Subject: [EXTERNAL] Re: Transmission of IPv6 Jumbograms as Atomic Fragments

EXT email: be mindful of links/attachments.

On Sat, 20 Nov 2021, 02:32 Templin (US), Fred L, <[email-masked]<mailto:[email-masked]>> wrote:

AH + JG

Fred

From: Mark Smith [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 18, 2021 4:11 PM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: Nick Hilliard <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: Transmission of IPv6 Jumbograms as Atomic Fragments

Regards,
Mark.

The AERO

Fred

---

From: David Farmer <[email-masked]>
Date: Fri, 19 Nov 2021 10:26:09 -0600

Well, then put it in your AERO/OMNI header, don't overload the
fragmentation header with it.

On Fri, Nov 19, 2021 at 10:18 AM Templin (US), Fred L <
[email-masked]> wrote:

> *Sent:* Friday, November 19, 2021 7:53 AM
> *Subject:* [EXTERNAL] Re: Transmission of IPv6 Jumbograms as Atomic
> Fragments
>
>
>
> On Sat, 20 Nov 2021, 02:32 Templin (US), Fred L, <

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 19 Nov 2021 16:29:58 +0000

Read the documents

From: David Farmer [mailto:[email-masked]]
Sent: Friday, November 19, 2021 8:26 AM
To: Templin (US), Fred L <[email-masked]>
Cc: Mark Smith <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: [EXTERNAL] Re: Transmission of IPv6 Jumbograms as Atomic Fragments

Well, then put it in your AERO/OMNI header, don't overload the fragmentation header with it.

On Fri, Nov 19, 2021 at 10:18 AM Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Fred

AH + JG

Fred

Regards,
Mark.

The AERO

Fred

David Farmer               Email:[email-masked]<mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Sat, 20 Nov 2021 04:06:33 +1100

> without reading documents.

Did you look up the AH spec? See section 2.5 Sequence Number.

As I said before, your description of replay protection is describing one
of the features of AH.

If you add that functionality to Jumbogram EHs, you are reinventing it
needlessly.

Combine AH EH with JG EH and you've got your jumbo packets with replay
protection.

You're not inventing anything new. The functionality to protect against
packet replaying already exists in AH (and ESP).

Regards,
Mark.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 19 Nov 2021 18:01:39 +0000

Mark, stop it with AH – the AERO/OMNI Identification sequence number management
scheme has its basis in RFC793. AERO/OMNI make ubiquitous use of the Fragment Header
for both fragmentation and packet identification, and adding an AH on every packet is neither
needed nor wanted.

Sent: Friday, November 19, 2021 9:07 AM

On Sat, 20 Nov 2021, 03:18 Templin (US), Fred L, <[email-masked]<mailto:[email-masked]>> wrote:

As I said before, your description of replay protection is describing one of the features of AH.

If you add that functionality to Jumbogram EHs, you are reinventing it needlessly.

Combine AH EH with JG EH and you've got your jumbo packets with replay protection.

You're not inventing anything new. The functionality to protect against packet replaying already exists in AH (and ESP).

Regards,
Mark.

Fred

AH + JG

Fred

Regards,
Mark.

The AERO

Fred

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 19 Nov 2021 18:37:10 +0000

Templin (US), Fred L wrote on 19/11/2021 18:01:
> Mark, stop it with AH – the AERO/OMNI Identification sequence number
> management scheme has its basis in RFC793. AERO/OMNI make ubiquitous
> use of the Fragment Header for both fragmentation and packet
> identification, and adding an AH on every packet is neither needed
> nor wanted.
Fred, if ipv6-out-of-the-box doesn't do exactly what AERO/OMNI needs it 
to do, and one of the easier ways to rectify this from the AERO/OMNI 
point of view is to change some bits of ipv6 that are notionally easy to 
change, that doesn't mean that this is necessarily a good idea for ipv6.

rfc793 specifies tcp, which is a stream-oriented protocol with lots of 
bells and whistles, but it's not ipv6:  it's a protocol which is layered 
on top of IP, so it's not viable to compare generic ipv6 datagram 
transmission with 793.  It looks like your suggestion is to 
short-circuit a couple of things together with the intention of ending 
up with something mid-way between a stream-oriented protocol like tcp, 
but to apply it to datagrams.  I assume the reason is to optimise on 
bandwidth because bandwidth to/from an aircraft is both expensive and 
potentially lossy, and encapsulation is unwelcome overhead.

Brian noted that packet identifiers are not part of the ipv6 
architecture. The reason is that this introduces state into the 
endpoints and middleboxes, and state is something that is basically 
incompatible with the concept of generic datagram mechanisms.

Maybe the difficulty here is that there are generic ways of doing what 
you want to do (i.e. stream-oriented transport, packet transmission via 
encapsulation, etc), but the cost of these is higher than you would want 
in the context of AERO/OMNI?  If so, then this is a difficult problem 
where there's a gap between what expedience hints at and what the 
architecture provides, with no easy way to bridge the gap.

Nick