Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number

[Carsten Bormann]

On 2022-09-08, at 18:08, Robert Moskowitz  wrote:
> 
> Thanks Tom!
> 
> Wow is that buried...  (IMHO)

Third hit for me under
https://www.google.com/search?q=IPv6-Compression-Protocol+Types+site%3Aiana.org

> The values seem to be all over the place.  Any insight as to why this is?

Hysterical raisins…
Header compression for IP started 42 years ago with RFC 1144 and has evolved a 
lot since then.  So did PPP.
(PPP also has these favorable and less favorable numbers, where what is 
favorable depends on what environment this will be used for.)

Grüße, Carsten



> 
> Bob
> 
> On 9/8/22 11:55, tom petch wrote:
>> From: Int-area  on behalf of Robert Moskowitz 
>> 
>> Sent: 08 September 2022 14:03
>> On 9/8/22 08:31, Pascal Thubert (pthubert) wrote:
>>> Hello Joel:
>>> 
>>> SCHC could be used to compress IP option headers and the residue be stored 
>>> in a SCHC option, which a next header points at uncompressed transport 
>>> (e.g., encrypted, uncompressible).
>>> Additionally, finding the SCHC context may require metadata that could also 
>>> be found in a SCHC option. Over one hop in LPWAN that is all implicit but 
>>> over IP it might not be.
>>> 
>>> SCHC is layered depending on which endpoint talks to which. E.g., you 
>>> compress a tunnel with inner that is already SCHC-compressed, you do 
>>> security, etc...
>>> So you could have SCHC options one after the other. We have not defined the 
>>> option yet, LPWAN is discussing recharter to cover SCHC applied beyond 
>>> LPWANs.
>>> 
>>> But since we're at it, let's do both in one RFC.
>>> Note that we'll also need a value for IPv6-Compression-Protocol Types, see 
>>> https://www.ietf.org/archive/id/draft-thubert-intarea-schc-over-ppp-03.html#name-iana-considerations.
>>> 
>> I cannot find this IANA registry.  Can someone please provide the URL.
>> 
>> Perhaps
>> https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-29
>> 
>> IP-Compression-Protocol Types in the Point-to-Point Protocol (PPP) Field 
>> Assignments  Group on the IANA website as set up by RFC1332.
>> 
>> Tom Petch
>> 
>> And this is why I have been instructed, and have adhered to, including
>> IANA URLs as informative references in my drafts.
>> 
>> Like in draft-moskowitz-intarea-schc-ip-protocol-number!
>> 
>> Bob
>> 
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number

[Robert Moskowitz]

Thanks Tom!

Wow is that buried...  (IMHO)

The values seem to be all over the place.  Any insight as to why this is?

Bob

On 9/8/22 11:55, tom petch wrote:

From: Int-area  on behalf of Robert Moskowitz 

Sent: 08 September 2022 14:03
On 9/8/22 08:31, Pascal Thubert (pthubert) wrote:

Hello Joel:

SCHC could be used to compress IP option headers and the residue be stored in a 
SCHC option, which a next header points at uncompressed transport (e.g., 
encrypted, uncompressible).
Additionally, finding the SCHC context may require metadata that could also be 
found in a SCHC option. Over one hop in LPWAN that is all implicit but over IP 
it might not be.

SCHC is layered depending on which endpoint talks to which. E.g., you compress 
a tunnel with inner that is already SCHC-compressed, you do security, etc...
So you could have SCHC options one after the other. We have not defined the 
option yet, LPWAN is discussing recharter to cover SCHC applied beyond LPWANs.

But since we're at it, let's do both in one RFC.
Note that we'll also need a value for IPv6-Compression-Protocol Types, see 
https://www.ietf.org/archive/id/draft-thubert-intarea-schc-over-ppp-03.html#name-iana-considerations.


I cannot find this IANA registry.  Can someone please provide the URL.

Perhaps
https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-29

IP-Compression-Protocol Types in the Point-to-Point Protocol (PPP) Field 
Assignments  Group on the IANA website as set up by RFC1332.

Tom Petch

And this is why I have been instructed, and have adhered to, including
IANA URLs as informative references in my drafts.

Like in draft-moskowitz-intarea-schc-ip-protocol-number!

Bob

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number

[tom petch]

From: Int-area  on behalf of Robert Moskowitz 

Sent: 08 September 2022 14:03
On 9/8/22 08:31, Pascal Thubert (pthubert) wrote:
> Hello Joel:
>
> SCHC could be used to compress IP option headers and the residue be stored in 
> a SCHC option, which a next header points at uncompressed transport (e.g., 
> encrypted, uncompressible).
> Additionally, finding the SCHC context may require metadata that could also 
> be found in a SCHC option. Over one hop in LPWAN that is all implicit but 
> over IP it might not be.
>
> SCHC is layered depending on which endpoint talks to which. E.g., you 
> compress a tunnel with inner that is already SCHC-compressed, you do 
> security, etc...
> So you could have SCHC options one after the other. We have not defined the 
> option yet, LPWAN is discussing recharter to cover SCHC applied beyond LPWANs.
>
> But since we're at it, let's do both in one RFC.
> Note that we'll also need a value for IPv6-Compression-Protocol Types, see 
> https://www.ietf.org/archive/id/draft-thubert-intarea-schc-over-ppp-03.html#name-iana-considerations.
>

I cannot find this IANA registry.  Can someone please provide the URL.

Perhaps
https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-29

IP-Compression-Protocol Types in the Point-to-Point Protocol (PPP) Field 
Assignments  Group on the IANA website as set up by RFC1332.

Tom Petch

And this is why I have been instructed, and have adhered to, including
IANA URLs as informative references in my drafts.

Like in draft-moskowitz-intarea-schc-ip-protocol-number!

Bob

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] New Liaison Statement, "Liaison on P802.1CQ Multicast and Local Address Assignment"

[Juan Carlos Zuniga (juzuniga)]

Dear IntArea WG,

As noted below, we have received a Liaison Letter regarding the IEEE P802.1CQ 
project, “(Draft) Standard for Local and Metropolitan Area Networks: Multicast 
and Local Address Assignment.”

If you are an individual interested in participating to this review, please 
contact the IntArea chairs directly and we can provide instructions on how to 
participate, as well as access to the draft document on the IEEE 802.1 file 
server.

Best,

Juan Carlos & Wassim
IntArea WG co-chairs

From: Liaison Statement Management Tool 
Date: Friday, September 2, 2022 at 4:20 PM
To: Juan Carlos Zuniga (juzuniga) , Wassim Haddad 

Cc: Eric Vyncke (evyncke) , Juan Carlos Zuniga (juzuniga) 
, Eric Gray , Erik Kline 
, Glenn Parsons , Internet Area 
Working Group Discussion List , John Messenger 
, Paul Nikolich , Wassim 
Haddad , liaison-coordinat...@iab.org 

Subject: New Liaison Statement, "Liaison on P802.1CQ Multicast and Local 
Address Assignment"
Title: Liaison on P802.1CQ Multicast and Local Address Assignment
Submission Date: 2022-09-02
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1794/

From: Glenn Parsons 
To: Juan-Carlos Zúñiga ,Wassim Haddad 

Cc: Erik Kline ,Internet Area Working Group Discussion List 
,Eric Gray ,Éric Vyncke 
,Wassim Haddad ,Juan-Carlos 
Zúñiga 
Response Contacts: Paul Nikolich ,Glenn Parsons 
,John Messenger 
Technical Contacts:
Purpose: For information

Body: The IEEE 802.1 Working Group would like to inform you that the IEEE 
P802.1CQ project, “(Draft)
Standard for Local and Metropolitan Area Networks: Multicast and Local Address 
Assignment,” has
initiated a Task Group ballot on draft 0.8.

We have learned, through the IETF/IEEE 802 Coordination process, that the IETF 
Internet Area
Working Group has an interest in P802.1CQ . 
We welcome your
review of and comments on the draft standard. We will send you details on how 
to access the draft so
you can provide access to those interested in participating in the review. We 
will also provide
instructions for submitting ballot comments. Ballot comment resolution will be 
conducted during one or
more of the electronic meetings of the TSN Task Group.

Note that the IEEE 802 work is open and contribution driven. Participation is 
on an individual basis and
technical discussion can be conducted based on individual contributions. The 
TSN Task Group holds
regular electronic meetings: details are available at 
https://1.ieee802.org/wg-calendar.
Attachments:

liaison-ietf-802-1CQ-1121-v02

https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2022-09-02-ieee-802-1-intarea-liaison-on-p8021cq-multicast-and-local-address-assignment-attachment-1.pdf

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number

[Robert Moskowitz]

With 20-20 hindsight and that ship long since sailed, we missed an 
opportunity years back to create "foo over UDP" by selecting a specific 
UDP port pair where the 1st byte after the UDP header was the 
IPv4Protocol/IPv6NextHeader field.


Might have made things simpler and enable more interesting things.

But that ship sailed long ago.

And since I have not been told what programmatic and/or operational item 
occurs for IP Extension Headers, I have no problem with dropping 
defining SCHC as an Internet Protocol Number as also a IP Extension 
Header type.


I just don't see any value in doing it.

Bob

On 9/8/22 09:48, Joel Halpern wrote:
There are multiple "protocols" that are essentially tunnel headers 
that use UDP.   Many of them have extension points in those headers. 
And almost all of them can carry IP packets which can themselves 
ccntain IP extension headers.


My view is that the registry for extension headers is not about 
whether the function of what is carried extends IP (many things not 
listed there effectively extend the IP header information) but whether 
the field beign defined is structurally an IP extension header.  Thus, 
I have no problem with SCHC supporting the various use cases Pascal 
describes without claiming that SCHC is an extension header.  
Structurally, it isn't an extension header.


Yours,

Joel

On 9/8/2022 3:38 AM, Antoine FRESSANCOURT wrote:

Hello,

Out of curiosity, as I am far less experienced than most people in 
this discussion, what do you have in mind when you mention " 
UDP-carrying headers-with-next-header as extension headers" ?


Thanks a lot for your clarifications,

Antoine Fressancourt

-Original Message-
From: Int-area  On Behalf Of Joel Halpern
Sent: mercredi 7 septembre 2022 23:54
To: Robert Moskowitz 
Cc: Internet Area 
Subject: Re: [Int-area] Resubmit - requesting WG Adoption 
draft-moskowitz-intarea-schc-ip-protocol-number


8200 implies that the first bye of the extension header is the next 
header field.  explicitly and visibly.  So that one can walk the next 
header chain.


I would like us to articulate a clear meaning of when something is an 
extension header.   I have tried to lay one such out. (Recognizing 
that there are a few historical exceptions).  If we want instead to 
redefine IP-in-IP and UDP-carrying headers-with-next-header as 
extension headers I wouldn't like it, but I could live with it.  Or 
we can say it si completely random I suppose.  Although I have 
trouble seeing how that is a good answer.


Yours,

Joel

PS: In case anyone is unclear, I am not criticizing Robert M. (or Bob 
H.).  He is trying to do the right thing.  And yes, we should give 
him a code point for this use.


On 9/7/2022 5:49 PM, Robert Moskowitz wrote:

ESP, RFC 4303 most DEFINITELY DOES have a Next Header Field.

It is just at the end of the datagram, before the ICV.


On 9/7/22 17:35, Joel Halpern wrote:

My reading of 8200 is that an extension header MUST start with a one
byte "Next Header" field.  SCHC does not.  Therefore, it is a carried
/ upper layer protocol, not an extension header.  Much like IPv6 (in
IPv6).  Or UDP (with carrying an application protocol or carrying
some routing header like GRE, LISP, ...) or ...

Yours,

Joel

PS: I grant we are not fully consistent in this regard.  ESP does not
have a next-header field.  (AH does).   But if we are going to
pretend that some headers are extensions headers and some are not, we
should try to be consistent with the description in 8200 (and 2460).

On 9/7/2022 4:57 PM, Robert Moskowitz wrote:


On 9/7/22 16:35, Carsten Bormann wrote:

On 7. Sep 2022, at 22:04, Bob Hinden  wrote:

To clarify my question, it only relates to if SCHC should be added
to the IPv6 Extension Header Types registry.   I continue to think
that adding it to the IP Protocol Number registry is fine.

I believe the answer should be the same as for 142 (RFC 5858),
which is not in the list.

I couldn’t find out quickly what an IPv6 Extension Header Type
is(*), so maybe that is an oversight for 142.

 From my limited understanding and which Protocols are listed as
Extension Header Types and which not (other than 142), it is a
Protocol that transports other Protocols.

Though with that definition, I wonder how HIP got in the list.

It is fun to open a can of worms!


Grüße, Carsten

(*) An IP protocol number, apparently.
But what specifically does it make an IPv6 Extension Header Type as
well?
The references given in the registry don’t seem to say.


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list

Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number

[Joel Halpern]

There are multiple "protocols" that are essentially tunnel headers that 
use UDP.   Many of them have extension points in those headers.  And 
almost all of them can carry IP packets which can themselves ccntain IP 
extension headers.


My view is that the registry for extension headers is not about whether 
the function of what is carried extends IP (many things not listed there 
effectively extend the IP header information) but whether the field 
beign defined is structurally an IP extension header.  Thus, I have no 
problem with SCHC supporting the various use cases Pascal describes 
without claiming that SCHC is an extension header.  Structurally, it 
isn't an extension header.


Yours,

Joel

On 9/8/2022 3:38 AM, Antoine FRESSANCOURT wrote:

Hello,

Out of curiosity, as I am far less experienced than most people in this discussion, what 
do you have in mind when you mention " UDP-carrying headers-with-next-header as 
extension headers" ?

Thanks a lot for your clarifications,

Antoine Fressancourt

-Original Message-
From: Int-area  On Behalf Of Joel Halpern
Sent: mercredi 7 septembre 2022 23:54
To: Robert Moskowitz 
Cc: Internet Area 
Subject: Re: [Int-area] Resubmit - requesting WG Adoption 
draft-moskowitz-intarea-schc-ip-protocol-number

8200 implies that the first bye of the extension header is the next header 
field.  explicitly and visibly.  So that one can walk the next header chain.

I would like us to articulate a clear meaning of when something is an extension 
header.   I have tried to lay one such out. (Recognizing that there are a few 
historical exceptions).  If we want instead to redefine IP-in-IP and 
UDP-carrying headers-with-next-header as extension headers I wouldn't like it, 
but I could live with it.  Or we can say it si completely random I suppose.  
Although I have trouble seeing how that is a good answer.

Yours,

Joel

PS: In case anyone is unclear, I am not criticizing Robert M. (or Bob H.).  He 
is trying to do the right thing.  And yes, we should give him a code point for 
this use.

On 9/7/2022 5:49 PM, Robert Moskowitz wrote:

ESP, RFC 4303 most DEFINITELY DOES have a Next Header Field.

It is just at the end of the datagram, before the ICV.


On 9/7/22 17:35, Joel Halpern wrote:

My reading of 8200 is that an extension header MUST start with a one
byte "Next Header" field.  SCHC does not.  Therefore, it is a carried
/ upper layer protocol, not an extension header.  Much like IPv6 (in
IPv6).  Or UDP (with carrying an application protocol or carrying
some routing header like GRE, LISP, ...) or ...

Yours,

Joel

PS: I grant we are not fully consistent in this regard.  ESP does not
have a next-header field.  (AH does).   But if we are going to
pretend that some headers are extensions headers and some are not, we
should try to be consistent with the description in 8200 (and 2460).

On 9/7/2022 4:57 PM, Robert Moskowitz wrote:


On 9/7/22 16:35, Carsten Bormann wrote:

On 7. Sep 2022, at 22:04, Bob Hinden  wrote:

To clarify my question, it only relates to if SCHC should be added
to the IPv6 Extension Header Types registry.   I continue to think
that adding it to the IP Protocol Number registry is fine.

I believe the answer should be the same as for 142 (RFC 5858),
which is not in the list.

I couldn’t find out quickly what an IPv6 Extension Header Type
is(*), so maybe that is an oversight for 142.

 From my limited understanding and which Protocols are listed as
Extension Header Types and which not (other than 142), it is a
Protocol that transports other Protocols.

Though with that definition, I wonder how HIP got in the list.

It is fun to open a can of worms!


Grüße, Carsten

(*) An IP protocol number, apparently.
But what specifically does it make an IPv6 Extension Header Type as
well?
The references given in the registry don’t seem to say.


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number

[Robert Moskowitz]

On 9/8/22 08:31, Pascal Thubert (pthubert) wrote:

Hello Joel:

SCHC could be used to compress IP option headers and the residue be stored in a 
SCHC option, which a next header points at uncompressed transport (e.g., 
encrypted, uncompressible).
Additionally, finding the SCHC context may require metadata that could also be 
found in a SCHC option. Over one hop in LPWAN that is all implicit but over IP 
it might not be.

SCHC is layered depending on which endpoint talks to which. E.g., you compress 
a tunnel with inner that is already SCHC-compressed, you do security, etc...
So you could have SCHC options one after the other. We have not defined the 
option yet, LPWAN is discussing recharter to cover SCHC applied beyond LPWANs.

But since we're at it, let's do both in one RFC.
Note that we'll also need a value for IPv6-Compression-Protocol Types, see 
https://www.ietf.org/archive/id/draft-thubert-intarea-schc-over-ppp-03.html#name-iana-considerations.



I cannot find this IANA registry.  Can someone please provide the URL.

And this is why I have been instructed, and have adhered to, including 
IANA URLs as informative references in my drafts.


Like in draft-moskowitz-intarea-schc-ip-protocol-number!

Bob

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number

[Pascal Thubert (pthubert)]

Hello Carsten

> > But it is architecturally wrong to call what ROHC or SCHC as carrying an
> upper layer protocol.  They carry what is in our architecture a Transport
> Layer protocol, acting in many ways as part of the IP layer itself…
> 
> Header Compression is organized layer violation, so even trying to assign
> a layer to it is futile.

As always, I love the way you're stating things

> Header Compression is usually done hop-by-hop as a local optimization,
> invisible to the endpoints; there is no end-to-end semantics that would be
> typical for a Transport Layer protocol.

With the neat that depending on what the layer is the endpoints are different.
See for instance 
https://www.rfc-editor.org/rfc/rfc8824.html#name-oscore-compression
So there can definitely be SCHC in SCHC, with different endpoints and rules.

For the PPP draft that uses SCHC as a PPP compression method, the endpoints are 
those of the PPP session. The architecture question is how to best structure 
the SCHC nesting.  
In Figure 7 of RFC 8824 the (encrypted) inner SCHC is concatenated to the 
residue of the outer SCHC. This means that the SCHC context is fully implicit 
and that the bits after the residue have to be the inner SCHC. Making those 2 
different SCHC headers would allow to decide for each layer whether SCHC is 
used or not, and pass enough info to avoid implicit deduction that may be 
misleading or constraining.
As far as RFC 8824 is great for LPWANs, I believe we need some better 
architectural structure when going to IP at large.




> The discussion so far about whether SCHC (or ROHC) would be IPv6 Extension
> Header Types seems to be rather sophistic to me, with little practical
> relevance of choosing one or the other.  Is there any behavior that would
> change based on whether they are IPv6 Extension Header Types or not?
> 
Yes, it seems to be placing the cart before the horse. But then again this is 
layer 0 of a stack of things we wish to achieve. So reserving the value in both 
registries, that's the same cost anyway.

All the best.

Pascal

> Grüße, Carsten
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number

[Pascal Thubert (pthubert)]

Hello Joel:

SCHC could be used to compress IP option headers and the residue be stored in a 
SCHC option, which a next header points at uncompressed transport (e.g., 
encrypted, uncompressible).
Additionally, finding the SCHC context may require metadata that could also be 
found in a SCHC option. Over one hop in LPWAN that is all implicit but over IP 
it might not be.

SCHC is layered depending on which endpoint talks to which. E.g., you compress 
a tunnel with inner that is already SCHC-compressed, you do security, etc... 
So you could have SCHC options one after the other. We have not defined the 
option yet, LPWAN is discussing recharter to cover SCHC applied beyond LPWANs. 

But since we're at it, let's do both in one RFC.
Note that we'll also need a value for IPv6-Compression-Protocol Types, see 
https://www.ietf.org/archive/id/draft-thubert-intarea-schc-over-ppp-03.html#name-iana-considerations.

All the best,

Pascal




> -Original Message-
> From: Int-area  On Behalf Of Joel Halpern
> Sent: mercredi 7 septembre 2022 23:35
> To: Robert Moskowitz ; Bob Hinden
> 
> Cc: Internet Area 
> Subject: Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-
> intarea-schc-ip-protocol-number
> 
> My reading of 8200 is that an extension header MUST start with a one byte
> "Next Header" field.  SCHC does not.  Therefore, it is a carried / upper
> layer protocol, not an extension header.  Much like IPv6 (in IPv6).  Or
> UDP (with carrying an application protocol or carrying some routing header
> like GRE, LISP, ...) or ...
> 
> Yours,
> 
> Joel
> 
> PS: I grant we are not fully consistent in this regard.  ESP does not have
> a next-header field.  (AH does).   But if we are going to pretend that
> some headers are extensions headers and some are not, we should try to be
> consistent with the description in 8200 (and 2460).
> 
> On 9/7/2022 4:57 PM, Robert Moskowitz wrote:
> >
> >
> > On 9/7/22 16:35, Carsten Bormann wrote:
> >> On 7. Sep 2022, at 22:04, Bob Hinden  wrote:
> >>> To clarify my question, it only relates to if SCHC should be added
> >>> to the IPv6 Extension Header Types registry.   I continue to think
> >>> that adding it to the IP Protocol Number registry is fine.
> >> I believe the answer should be the same as for 142 (RFC 5858), which
> >> is not in the list.
> >>
> >> I couldn’t find out quickly what an IPv6 Extension Header Type is(*),
> >> so maybe that is an oversight for 142.
> >
> > From my limited understanding and which Protocols are listed as
> > Extension Header Types and which not (other than 142), it is a
> > Protocol that transports other Protocols.
> >
> > Though with that definition, I wonder how HIP got in the list.
> >
> > It is fun to open a can of worms!
> >
> >>
> >> Grüße, Carsten
> >>
> >> (*) An IP protocol number, apparently.
> >> But what specifically does it make an IPv6 Extension Header Type as
> >> well?
> >> The references given in the registry don’t seem to say.
> >>
> >
> > ___
> > Int-area mailing list
> > Int-area@ietf.org
> > https://www.ietf.org/mailman/listinfo/int-area
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Can you review draft-ietf-ipsecme-iptfs as it is about tunnels

[Eric Vyncke (evyncke)]

Merci Antoine for your review.

When I updated my ballot position [1] from DISCUSS to NO OBJECTION, I have also 
referred to your email and strongly asked the authors for a reply.

Regards

-éric

[1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ballot/


From: Antoine FRESSANCOURT 
Date: Monday, 5 September 2022 at 15:12
To: Eric Vyncke , Internet Area , 
"int-...@ietf.org" 
Cc: "ip...@ietf.org" 
Subject: RE: Can you review draft-ietf-ipsecme-iptfs as it is about tunnels

Hello,

Following the message from E. Vyncke on the Int-Area mailing list, I have made 
a review of draft-ietf-ipsecme-iptfs-19. As it is my first draft review, I hope 
it will bring value to the author. I am of course happy to discuss comments on 
list or off list.

The draft draft-ietf-ipsecme-iptfs-19 proposes a mechanism to obfuscate and 
anonymize flows going through an IPSec tunnel. In the proposed mechanism, 
packets of fixed size are sent at a constant rate in the tunnel. Packets 
traversing the tunnel may be multiplexed or fragmented in the tunnel using an 
AGGFRAG payload conveyed in the ESP of an IP packet. One of the benefits of 
this mechanism compared to previously presented mechanism is to improve the 
bandwidth efficiency and improve the throughput for packets inside the tunnel.

This work solves an important security / privacy attack, the traffic flow 
correlation attack, consisting in analyzing the pace and size of packets 
exchanged between hosts to determine which application is used. Recently, 
authors of the paper ditto: WAN Traffic Obfuscation at Line Rate [1] have 
presented a solution similar to the solution presented in this draft. Note that 
this work could appear in the implementation section 8 as the authors have 
published an open source implementation of their work (Or in the informative 
references).

I have two major remarks about the document:

1/ In section 2.4.1, the author mentions that “Non-congestion-controlled mode 
is also appropriate if ESP over TCP is in use [RFC8229].  However, the use of 
TCP is considered a highly non-preferred, and a fall-back only solution for 
IPsec.  This is also one of the reasons that TCP was not chosen as the 
encapsulation for IP-TFS instead of AGGFRAG.”. while no mention of QUIC is 
made. I understand that the draft has been in the work for a rather long period 
of time, and that some recent QUIC work have popped out while it was in the 
making, yet I think it would be interesting to position this draft with regards 
to RFC 9221 (An Unreliable Datagram Extension to QUIC) given that QUIC now 
provides some tools and mechanisms that are similar to the tools needed by the 
authors (alas at a different layer, which is a major difference between the 
mechanism proposed in the draft and QUIC)

2/ About the congestion mode, the draft is referring to RFCs 3168 and 6040, 
which discuss the potential problems associated with the use of ECN in an IP in 
IP tunneling mechanism. As ECN is not protected in IP Sec, the Security 
Considerations section explicitly discourages from using ECN by default. Yet, I 
think that some threats related to the use of the congestion mode in this draft 
should be explicitly stated in the document. For instance, adding congestion on 
links taken by the tunnel can force the receiver end of the tunnel to signal 
that congestion is experienced. An observer being able to look at the sender 
end’s inbound traffic could determine which flows / other tunnels are delayed 
in front of this congestion event, leading the attacker to gain information 
about the tunnel’s users. This attack requires a rather powerful attacker, yet 
is considered feasible in the literature about privacy-preserving 
communication. I would discuss this potential threat in the Security 
Considerations section as a complement to the paragraph about ECN.

Overall, I think the draft is very interesting, that the technology it presents 
is useful and while I would appreciate some answers to remarks I have made, I 
think it is ready for the next stage.

Best regards,

Antoine Fressancourt

[1] Meier, Roland, Vincent Lenders, and Laurent Vanbever. "ditto: WAN Traffic 
Obfuscation at Line Rate." NDSS Symposium 2022. 2022.


From: Int-area  On Behalf Of Eric Vyncke (evyncke)
Sent: mercredi 10 août 2022 17:52
To: Internet Area ; int-...@ietf.org
Cc: ip...@ietf.org
Subject: [Int-area] Can you review draft-ietf-ipsecme-iptfs as it is about 
tunnels

Dear intarea/int-dir,

I have a request for you about 
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/

While the draft name looks like it is about IPsec, it appears to me as an 
“aggregation and fragmentation” tunneling mechanism [1], i.e., it uses the ESP 
Next-header field (an IP protocol per section 2.6 of RFC 4303 == IPsec ESP) to 
indicate a next protocol. While the original intent is to prevent traffic 
analysis (based on packet size and rate of packets) by 
padding/aggregating/fragmenting packets, it is also a 

Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number

[Antoine FRESSANCOURT]

Hello,

Out of curiosity, as I am far less experienced than most people in this 
discussion, what do you have in mind when you mention " UDP-carrying 
headers-with-next-header as extension headers" ?

Thanks a lot for your clarifications,

Antoine Fressancourt

-Original Message-
From: Int-area  On Behalf Of Joel Halpern
Sent: mercredi 7 septembre 2022 23:54
To: Robert Moskowitz 
Cc: Internet Area 
Subject: Re: [Int-area] Resubmit - requesting WG Adoption 
draft-moskowitz-intarea-schc-ip-protocol-number

8200 implies that the first bye of the extension header is the next header 
field.  explicitly and visibly.  So that one can walk the next header chain.

I would like us to articulate a clear meaning of when something is an extension 
header.   I have tried to lay one such out. (Recognizing that there are a few 
historical exceptions).  If we want instead to redefine IP-in-IP and 
UDP-carrying headers-with-next-header as extension headers I wouldn't like it, 
but I could live with it.  Or we can say it si completely random I suppose.  
Although I have trouble seeing how that is a good answer.

Yours,

Joel

PS: In case anyone is unclear, I am not criticizing Robert M. (or Bob H.).  He 
is trying to do the right thing.  And yes, we should give him a code point for 
this use.

On 9/7/2022 5:49 PM, Robert Moskowitz wrote:
> ESP, RFC 4303 most DEFINITELY DOES have a Next Header Field.
>
> It is just at the end of the datagram, before the ICV.
>
>
> On 9/7/22 17:35, Joel Halpern wrote:
>> My reading of 8200 is that an extension header MUST start with a one 
>> byte "Next Header" field.  SCHC does not.  Therefore, it is a carried 
>> / upper layer protocol, not an extension header.  Much like IPv6 (in 
>> IPv6).  Or UDP (with carrying an application protocol or carrying 
>> some routing header like GRE, LISP, ...) or ...
>>
>> Yours,
>>
>> Joel
>>
>> PS: I grant we are not fully consistent in this regard.  ESP does not 
>> have a next-header field.  (AH does).   But if we are going to 
>> pretend that some headers are extensions headers and some are not, we 
>> should try to be consistent with the description in 8200 (and 2460).
>>
>> On 9/7/2022 4:57 PM, Robert Moskowitz wrote:
>>>
>>>
>>> On 9/7/22 16:35, Carsten Bormann wrote:
 On 7. Sep 2022, at 22:04, Bob Hinden  wrote:
> To clarify my question, it only relates to if SCHC should be added 
> to the IPv6 Extension Header Types registry.   I continue to think 
> that adding it to the IP Protocol Number registry is fine.
 I believe the answer should be the same as for 142 (RFC 5858), 
 which is not in the list.

 I couldn’t find out quickly what an IPv6 Extension Header Type 
 is(*), so maybe that is an oversight for 142.
>>>
>>> From my limited understanding and which Protocols are listed as 
>>> Extension Header Types and which not (other than 142), it is a 
>>> Protocol that transports other Protocols.
>>>
>>> Though with that definition, I wonder how HIP got in the list.
>>>
>>> It is fun to open a can of worms!
>>>

 Grüße, Carsten

 (*) An IP protocol number, apparently.
 But what specifically does it make an IPv6 Extension Header Type as 
 well?
 The references given in the registry don’t seem to say.

>>>
>>> ___
>>> Int-area mailing list
>>> Int-area@ietf.org
>>> https://www.ietf.org/mailman/listinfo/int-area
>

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area