Re: [IPsec] Martin Duke's Discuss on draft-ietf-ipsecme-iptfs-13: (with DISCUSS and COMMENT)

[Christian Hopps]

Martin Duke  writes:


Thanks for the explanation of the half-duplex mode.

Would it be too much to include the following requirements? You seem
to think they are redundant but they are not obvious to me from
reading the text.

Senders MUST encode a BlockLength consistent with the immediately
preceding packet. Specifically, if the immediately preceding packet
had a Pad Data Block, the
BlockLength MUST be zero, as Pad Data Blocks cannot be fragmented.
The BlockLength MUST be consistent with the remaining size implied by
the native length
encoding of the fragmented inner packet.

To account for misbehaving senders, a receiver SHOULD gracefully
handle the case where the BlockLengths of consecutive packets, and/or
the inner packet they
share, do not agree. It MAY drop the inner packet, or one or both of
the outer packets.


Can do.

Thanks,
Chris.



Martin

On Wed, Aug 10, 2022 at 12:32 PM Christian Hopps 
wrote:


Martin Duke  writes:

> Comments inline.
>
> On Tue, Aug 9, 2022 at 8:56 PM Christian Hopps <
cho...@chopps.org>
> wrote:
>
>
>     Thanks for the thorough review! Comments inline..
>
>     Martin Duke via Datatracker  writes:
>
>     > (6) As malformed packets are sometimes an attack vector,
it
>     would be good to
>     > specify behavior in response to pathological
BlockOffsets, for
>     instance:
>     >
>     > - What if two BlockOffset fields disagree? e.g., with 500
byte
>     outer packets,
>     > what if the sequence of block offsets is {0, 750, 100}?
Does
>     the third packet
>     > have 250 or 100 bytes of the first data block? Drop the
packet,
>     kill the SA,
>     > ignore one and accept the other, or something else?
>
>     The block offset is pointing at the start of the next
packet
>     (which may be beyond the current packets boundary). So it
also
>     represents what is left in the current inner packet being
>     reassembled. When the offset doesn't agree with the known
length
>     of the inner being reassembled, the inner is simply dropped
and
>     you move to the start of the next packet (which is what the
block
>     offset points to).
>
>     It should be noted that these values are in the cipher text
(i.e.
>     they are encrypted inside the ESP wrapper), so getting bad
values
>     here is almost for sure due to a bug/corruption on a
validated
>     sender rather than an attack. :)
>
>
> Do I understand correctly that the inner packet's native length
field
> is the ground truth, rather than the block offset? I actually
don't
> care how these conflicts are resolved, just that the text
resolves
> them.

That's correct, it's the only place the actual length is, no
duplication. The block offset always points at the start of the
next packet.

>From 2.2.1:

   Likewise, the
   length of the data block is extracted from the encapsulated
IPv4's
   Total Length or IPv6's Payload Length fields.

>From 2.2:
   [.. diagram showing "DataBlocks" and "BlockOffset" ..]

   If the BlockOffset value is zero it means that the DataBlocks
data
   begins with a new data block.

   Conversely, if the BlockOffset value is non-zero it points to
the
   start of the new data block, and the initial DataBlocks data
belongs
   to the data block that is still being re-assembled.


> I am not an expert on these attacks, nor do I have a
well-thought-out
> threat model, but IIUC these sorts of problems usually manifest
as
> buffer overflows and the like, not as injected packets. In any
case,
> it's better to have well-defined protocol behavior on
unexpected
> input.
>  
>
>
>     > - What if a pad block is in a packet with a BlockOffset
greater
>     than the packet
>     > length? Would the receiver skip over the specified bytes
in the
>     subsequent
>     > packet, even though padding is supposed to only be at the
end
>     of packets?
>
>     This situation can't occur as pad blocks are very simple
and hard
>     to mess up. :) Pad blocks start with 4 0-bits and their
length is
>     "the rest of the packet". By definition if the block offset
>     points past the end of the outer packet, there is no pad
and the
>     payload is entirely made up of the current inner packet
being
>     reassembled.
>
>
> OK. The document seems to define a pad block as a kind of data
block,
> and the BlockOffset field applies to data blocks. So it would
be
> legal to have an all-padding packet with a BlockOffset > outer
packet
> size, IIUC.

No, pad blocks are always from their start to the end of the
outer packet. You would never be 

Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-02.txt

[Michael Richardson]

Robert Moskowitz  wrote:
> Here is the latest revision.

> Should this draft be adopted by the workgroup for 'proper' document
> advancing?

adopt it, and WGLC it.
It's done.



signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-rfc8229bis-07: (with DISCUSS)

[Warren Kumari]

On Wed, Aug 10, 2022 at 5:39 PM, Valery Smyslov  wrote:

> Please see inline.
>
>
>
> On Wed, Aug 10, 2022 at 4:37 PM, Valery Smyslov < svan@
> elvis.ru> wrote:
>
> Hi Warren,
>
> thank you for this discussion, please see inline.
>
> Warren Kumari has entered the following ballot position for
> draft-ietf-ipsecme-rfc8229bis-07: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/
> handling- ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/
>
> --
> DISCUSS:
> --
>
> Do not panic!
>
> By no means :-)
>
> This should be trivial to address, probably by pointing me at something
> that I missed (very likely), or by dropping in a sentence to two into the
> document.
>
> The document starts off with: "This document describes a method to
> transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP
> connection for traversing network middleboxes that may block IKE
> negotiation over UDP."
>
> As far as I can tell (and again, it is likely that I missed something!) it
> doesn't really discuss the fact that the operator may be intentionally
> blocking IKE. For example, many enterprises really don't want their users
> to be building IPSec tunnels into/out of their network because they want to
> do DLP, firewalling, and so they block IKE to block IPSec. This may be a
> flawed concept, and you and I may think that it's a losing battle, but I
> really think that the document needs to at least discuss that this
> potentially bypasses intentional security controls.
>
> This document is not intended to provide a mechanism to bypass intentional
> security controls.
>
>
>
> Excellent!
>
>
>
>
>
> In most cases IKE is blocked not because operators want do DLP etc., but
> because operators of small hotels, cafe, internet kiosks often block all
> UDP except DNS and sometimes block all TCP except http / https too.
>
>
>
> Yup.
>
>
>
> I can only imagine why they do it, my guess is "just in case".
>
>
>
>
>
> Yup, agreed.
>
>
>
>
>
> This is a real problem and our experience shows that it's impossible to
> solve by an IPsec user who appeared in the situation when UDP is blocked in
> a hotel he stayed in.
>
>
>
>
>
> Oh, yeah, I fully agree.
>
>
>
> Operators wanting to block IKE because of security implications may also
> block TCP port 4500 and use DLP to filter out TCP streams started with
> IKETCP, so they can deal with this specification.
>
>
>
> Yes, yes they can — but I suspect that many currently aren't.
>
>
>
> What would satisfy me would be something like a sentence saying something
> along the lines of "Operators who intentionally want to block IKE because
> of security implications should also block TCP port 4500 and use DLP to
> filter out TCP streams started with IKETCP".
>
>
>
> This seems like a simple addition to help prevent people shooting
> themselves in the foot (or, at least that we can point to if they do :-))
>
>
>
>   I've added the following text at the end of the Middlebox
> Considerations section:
>
>
>
> Operators who intentionally block IPsec because of security
> implications
>
> may want to also block TCP port 4500 or use DLP to filter out TCP
> connections started with IKETCP stream prefix.
>
>
>
>   Is it OK? (Tommy will review the changes, so he may want to make
> some additional tweaks).
>


Awesome, thank you very much for so quickly addressing my concerns - I have
cleared my discuss and balloted Yes.

Thanks again,
W



>
>   Regards,
>
>   Valery.
>
>
>
>
>
>
>
> W
>
>
>
> Besides, there may be future IKE extensions that rely on TCP transport
> (e.g. for transferring large PQ public keys, see
> draft-tjhai-ikev2-beyond-64k-limit). In this case TCP is used not because
> UDP is blocked, but because sending 1MB data over UDP with no congestion
> control is not a good idea. This is not yet a WG document, so it is not
> referenced in the draft, but we keep it in mind.
>
> Hope this helps.
>
> Regards,
> Valery.
>
> See:
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Warren Kumari's Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-ipsecme-rfc8229bis-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/



--
COMMENT:
--

Thank you very much for addressing my DISCUSS concerns.



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-02.txt

[Robert Moskowitz]

Here is the latest revision.

Should this draft be adopted by the workgroup for 'proper' document 
advancing?


thanks

Bob



 Forwarded Message 
Subject: 	New Version Notification for 
draft-moskowitz-ipsecme-ipseckey-eddsa-02.txt

Date:   Wed, 10 Aug 2022 14:45:05 -0700
From:   internet-dra...@ietf.org
To: 	Robert Moskowitz , Tero Kivinen 






A new version of I-D, draft-moskowitz-ipsecme-ipseckey-eddsa-02.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-ipsecme-ipseckey-eddsa
Revision: 02
Title: EdDSA value for IPSECKEY
Document date: 2022-08-10
Group: Individual Submission
Pages: 4
URL: 
https://www.ietf.org/archive/id/draft-moskowitz-ipsecme-ipseckey-eddsa-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-ipsecme-ipseckey-eddsa/
Html: 
https://www.ietf.org/archive/id/draft-moskowitz-ipsecme-ipseckey-eddsa-02.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-ipsecme-ipseckey-eddsa
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-moskowitz-ipsecme-ipseckey-eddsa-02


Abstract:
This document assigns a value for EdDSA Public Keys to the IPSECKEY
IANA registry.



The IETF Secretariat

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-rfc8229bis-07: (with DISCUSS)

[Valery Smyslov]

Please see inline.

 

On Wed, Aug 10, 2022 at 4:37 PM, Valery Smyslov <  
s...@elvis.ru> wrote:

Hi Warren, 

thank you for this discussion, please see inline. 

Warren Kumari has entered the following ballot position for 
draft-ietf-ipsecme-rfc8229bis-07: Discuss 

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.) 

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling- 
ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions. 

The document, along with other ballot positions, can be found here: 
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/ 

-- DISCUSS: 
-- 

Do not panic! 

By no means :-) 

This should be trivial to address, probably by pointing me at something that I 
missed (very likely), or by dropping in a sentence to two into the document. 

The document starts off with: "This document describes a method to transport 
Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection 
for traversing network middleboxes that may block IKE negotiation over UDP." 

As far as I can tell (and again, it is likely that I missed something!) it 
doesn't really discuss the fact that the operator may be intentionally blocking 
IKE. For example, many enterprises really don't want their users to be building 
IPSec tunnels into/out of their network because they want to do DLP, 
firewalling, and so they block IKE to block IPSec. This may be a flawed 
concept, and you and I may think that it's a losing battle, but I really think 
that the document needs to at least discuss that this potentially bypasses 
intentional security controls. 

This document is not intended to provide a mechanism to bypass intentional 
security controls. 

 

Excellent!

 

 

In most cases IKE is blocked not because operators want do DLP etc., but 
because operators of small hotels, cafe, internet kiosks often block all UDP 
except DNS and sometimes block all TCP except http / https too.

 

Yup.

 

I can only imagine why they do it, my guess is "just in case". 

 

 

Yup, agreed.

 

 

This is a real problem and our experience shows that it's impossible to solve 
by an IPsec user who appeared in the situation when UDP is blocked in a hotel 
he stayed in.

 

 

Oh, yeah, I fully agree.

 

Operators wanting to block IKE because of security implications may also block 
TCP port 4500 and use DLP to filter out TCP streams started with IKETCP, so 
they can deal with this specification.

 

Yes, yes they can — but I suspect that many currently aren't.

 

What would satisfy me would be something like a sentence saying something along 
the lines of "Operators who intentionally want to block IKE because of security 
implications should also block TCP port 4500 and use DLP to filter out TCP 
streams started with IKETCP".

 

This seems like a simple addition to help prevent people shooting themselves in 
the foot (or, at least that we can point to if they do :-))

 

  I've added the following text at the end of the Middlebox 
Considerations section:

 

Operators who intentionally block IPsec because of security 
implications 

may want to also block TCP port 4500 or use DLP to filter out TCP 
connections started with IKETCP stream prefix.



  Is it OK? (Tommy will review the changes, so he may want to make some 
additional tweaks).

 

  Regards,

  Valery.

 

  

 

W

 

Besides, there may be future IKE extensions that rely on TCP transport 
(e.g. for transferring large PQ public keys, see 
draft-tjhai-ikev2-beyond-64k-limit). In this case TCP is used not because UDP 
is blocked, but because sending 1MB data over UDP with no congestion control is 
not a good idea. This is not yet a WG document, so it is not referenced in the 
draft, but we keep it in mind. 

Hope this helps. 

Regards, 
Valery. 

See: 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot- positions/

 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt

[Robert Moskowitz]

On 8/10/22 16:45, Paul Wouters wrote:



On Aug 10, 2022, at 16:07, Robert Moskowitz  
wrote:




On 8/10/22 16:04, Paul Wouters wrote:

Robert Moskowitz  wrote:


I think I could have the IANA Considerations have a fix for 1 - 3 as
well as add 4.

Please do. I talked to IANA and they agreed this was the easiest solution.  


Should it be:

  * public key
  * Public key
  * Public Key



My preference is Public Key but I don’t feel strongly at all - either 
of these are fine for me.


It is all about is it a Proper Noun or not.

Well, in the end, it will be up to the RFC Editor!  :)



Here goes:


Looks good, thanks !

Paul



4.1.  IANA IPSECKEY Registry Update

   This document requests IANA to clarify the text in the "Algorithm
   Type Field" subregistry of the "IPSECKEY Resource Record Parameters"
   [IANA-IPSECKEY] registry to explicitly state this is for "Public"
   keys:

Value Description Reference

1    A DSA Public key is present, in the format defined in 
[RFC2536]    [RFC4025]
2    A RSA Public key is present, in the format defined in 
[RFC3110]    [RFC4025]
3    An ECDSA Public key is present, in the format defined in 
[RFC6605] [RFC8005]



   Futher, this document requests IANA to make the following addition to
   the "IPSECKEY Resource Record Parameters" [IANA-IPSECKEY] registry:

   IPSECKEY:
  This document defines the new IPSECKEY value TBD1 (suggested: 4)
  (Section 3) in the "Algorithm Type Field" subregistry of the
  "IPSECKEY Resource Record Parameters" registry.

  Value  Description Reference

  TBD1 (suggested value 4)   [This]
 An EdDSA Public key is present, in the format defined
 in [RFC8080]

==
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-rfc8229bis-07: (with DISCUSS)

[Warren Kumari]

On Wed, Aug 10, 2022 at 4:37 PM, Valery Smyslov  wrote:

> Hi Warren,
>
> thank you for this discussion, please see inline.
>
> Warren Kumari has entered the following ballot position for
> draft-ietf-ipsecme-rfc8229bis-07: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/
> handling- ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/
>
> --
> DISCUSS:
> --
>
> Do not panic!
>
> By no means :-)
>
> This should be trivial to address, probably by pointing me at something
> that I missed (very likely), or by dropping in a sentence to two into the
> document.
>
> The document starts off with: "This document describes a method to
> transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP
> connection for traversing network middleboxes that may block IKE
> negotiation over UDP."
>
> As far as I can tell (and again, it is likely that I missed something!) it
> doesn't really discuss the fact that the operator may be intentionally
> blocking IKE. For example, many enterprises really don't want their users
> to be building IPSec tunnels into/out of their network because they want to
> do DLP, firewalling, and so they block IKE to block IPSec. This may be a
> flawed concept, and you and I may think that it's a losing battle, but I
> really think that the document needs to at least discuss that this
> potentially bypasses intentional security controls.
>
> This document is not intended to provide a mechanism to bypass intentional
> security controls.
>

Excellent!


In most cases IKE is blocked not because operators want do DLP etc., but
> because operators of small hotels, cafe, internet kiosks often block all
> UDP except DNS and sometimes block all TCP except http / https too.
>

Yup.

I can only imagine why they do it, my guess is "just in case".
>


Yup, agreed.


This is a real problem and our experience shows that it's impossible to
> solve by an IPsec user who appeared in the situation when UDP is blocked in
> a hotel he stayed in.
>


Oh, yeah, I fully agree.

>
> Operators wanting to block IKE because of security implications may also
> block TCP port 4500 and use DLP to filter out TCP streams started with
> IKETCP, so they can deal with this specification.
>

Yes, yes they can — but I suspect that many currently aren't.

What would satisfy me would be something like a sentence saying something
along the lines of "Operators who intentionally want to block IKE because
of security implications should also block TCP port 4500 and use DLP to
filter out TCP streams started with IKETCP".

This seems like a simple addition to help prevent people shooting
themselves in the foot (or, at least that we can point to if they do :-))

W

>
> Besides, there may be future IKE extensions that rely on TCP transport
> (e.g. for transferring large PQ public keys, see
> draft-tjhai-ikev2-beyond-64k-limit). In this case TCP is used not because
> UDP is blocked, but because sending 1MB data over UDP with no congestion
> control is not a good idea. This is not yet a WG document, so it is not
> referenced in the draft, but we keep it in mind.
>
> Hope this helps.
>
> Regards,
> Valery.
>
> See:
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt

[Paul Wouters]

> On Aug 10, 2022, at 16:07, Robert Moskowitz  wrote:
> 
>  
> 
>> On 8/10/22 16:04, Paul Wouters wrote:
>>> Robert Moskowitz  wrote:
>>> 
 I think I could have the IANA Considerations have a fix for 1 - 3 as
 well as add 4.
>> Please do. I talked to IANA and they agreed this was the easiest solution.   
> 
> Should it be:
> 
> public key
> Public key
> Public Key

My preference is Public Key but I don’t feel strongly at all - either of these 
are fine for me.
> Here goes:

Looks good, thanks !

Paul

> 
> 4.1.  IANA IPSECKEY Registry Update
> 
>This document requests IANA to clarify the text in the "Algorithm
>Type Field" subregistry of the "IPSECKEY Resource Record Parameters"
>[IANA-IPSECKEY] registry to explicitly state this is for "Public"
>keys:
> 
> Value  Description  
> Reference
> 
> 1A DSA Public key is present, in the format defined in [RFC2536]
> [RFC4025]
> 2A RSA Public key is present, in the format defined in [RFC3110]
> [RFC4025]
> 3An ECDSA Public key is present, in the format defined in [RFC6605] 
> [RFC8005]
> 
> 
>Futher, this document requests IANA to make the following addition to
>the "IPSECKEY Resource Record Parameters" [IANA-IPSECKEY] registry:
> 
>IPSECKEY:
>   This document defines the new IPSECKEY value TBD1 (suggested: 4)
>   (Section 3) in the "Algorithm Type Field" subregistry of the
>   "IPSECKEY Resource Record Parameters" registry.
> 
>   Value  Description Reference
> 
>   TBD1 (suggested value 4)   [This]
>  An EdDSA Public key is present, in the format defined
>  in [RFC8080]
> 
> ==
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-rfc8229bis-07: (with DISCUSS)

[Valery Smyslov]

Hi Warren,

thank you for this discussion, please see inline.

> Warren Kumari has entered the following ballot position for
> draft-ietf-ipsecme-rfc8229bis-07: Discuss
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-
> ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Do not panic!

By no means :-)

> This should be trivial to address, probably by pointing me at something that I
> missed (very likely), or by dropping in a sentence to two into the document.
> 
> The document starts off with: "This document describes a method to transport
> Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection
> for traversing network middleboxes that may block IKE negotiation over UDP."
> 
> As far as I can tell (and again, it is likely that I missed something!) it
> doesn't really discuss the fact that the operator may be intentionally 
> blocking
> IKE. For example, many enterprises really don't want their users to be 
> building
> IPSec tunnels into/out of their network because they want to do DLP,
> firewalling, and so they block IKE to block IPSec. This may be a flawed
> concept, and you and I may think that it's a losing battle, but I really think
> that the document needs to at least discuss that this potentially bypasses
> intentional security controls.

This document is not intended to provide a mechanism to bypass intentional
security controls. In most cases IKE is blocked not because operators
want do DLP etc., but because operators of small hotels, cafe, internet
kiosks often block all UDP except DNS and sometimes block all TCP except http / 
https too. 
I can only imagine why they do it, my guess is "just in case".
This is a real problem and our experience shows that it's impossible to solve 
by an IPsec user
who appeared in the situation when UDP is blocked in a hotel he stayed in.

Operators wanting to block IKE because of security implications may also 
block TCP port 4500 and use DLP to filter out TCP streams started with IKETCP,
so they can deal with this specification. 

Besides, there may be future IKE extensions that rely on TCP transport
(e.g. for transferring large PQ public keys, see 
draft-tjhai-ikev2-beyond-64k-limit).
In this case TCP is used not because UDP is blocked, but because 
sending 1MB data over UDP with no congestion control is not a good idea.
This is not yet a WG document, so it is not referenced in the draft, 
but we keep it in mind.

Hope this helps.

Regards,
Valery.

> See:
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> 
> 
> 
> 


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt

[Robert Moskowitz]

On 8/10/22 16:04, Paul Wouters wrote:

Robert Moskowitz  wrote:


I think I could have the IANA Considerations have a fix for 1 - 3 as
well as add 4.

Please do. I talked to IANA and they agreed this was the easiest solution.  


Should it be:

 * public key
 * Public key
 * Public Key

??


Here goes:

4.1.  IANA IPSECKEY Registry Update

   This document requests IANA to clarify the text in the "Algorithm
   Type Field" subregistry of the "IPSECKEY Resource Record Parameters"
   [IANA-IPSECKEY] registry to explicitly state this is for "Public"
   keys:

Value Description Reference

1    A DSA Public key is present, in the format defined in [RFC2536]    
[RFC4025]
2    A RSA Public key is present, in the format defined in [RFC3110]    
[RFC4025]
3    An ECDSA Public key is present, in the format defined in [RFC6605] 
[RFC8005]



   Futher, this document requests IANA to make the following addition to
   the "IPSECKEY Resource Record Parameters" [IANA-IPSECKEY] registry:

   IPSECKEY:
  This document defines the new IPSECKEY value TBD1 (suggested: 4)
  (Section 3) in the "Algorithm Type Field" subregistry of the
  "IPSECKEY Resource Record Parameters" registry.

  Value  Description Reference

  TBD1 (suggested value 4)   [This]
 An EdDSA Public key is present, in the format defined
 in [RFC8080]

==___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt

[Paul Wouters]

> 
> Robert Moskowitz  wrote:
> 
>> I think I could have the IANA Considerations have a fix for 1 - 3 as
>> well as add 4.

Please do. I talked to IANA and they agreed this was the easiest solution.

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Martin Duke's Discuss on draft-ietf-ipsecme-iptfs-13: (with DISCUSS and COMMENT)

[Martin Duke]

Thanks for the explanation of the half-duplex mode.

Would it be too much to include the following requirements? You seem to
think they are redundant but they are not obvious to me from reading the
text.

Senders MUST encode a BlockLength consistent with the immediately preceding
packet. Specifically, if the immediately preceding packet had a Pad Data
Block, the
BlockLength MUST be zero, as Pad Data Blocks cannot be fragmented. The
BlockLength MUST be consistent with the remaining size implied by the
native length
encoding of the fragmented inner packet.

To account for misbehaving senders, a receiver SHOULD gracefully handle the
case where the BlockLengths of consecutive packets, and/or the inner packet
they
share, do not agree. It MAY drop the inner packet, or one or both of the
outer packets.

Martin

On Wed, Aug 10, 2022 at 12:32 PM Christian Hopps  wrote:

>
> Martin Duke  writes:
>
> > Comments inline.
> >
> > On Tue, Aug 9, 2022 at 8:56 PM Christian Hopps 
> > wrote:
> >
> >
> > Thanks for the thorough review! Comments inline..
> >
> > Martin Duke via Datatracker  writes:
> >
> > > (6) As malformed packets are sometimes an attack vector, it
> > would be good to
> > > specify behavior in response to pathological BlockOffsets, for
> > instance:
> > >
> > > - What if two BlockOffset fields disagree? e.g., with 500 byte
> > outer packets,
> > > what if the sequence of block offsets is {0, 750, 100}? Does
> > the third packet
> > > have 250 or 100 bytes of the first data block? Drop the packet,
> > kill the SA,
> > > ignore one and accept the other, or something else?
> >
> > The block offset is pointing at the start of the next packet
> > (which may be beyond the current packets boundary). So it also
> > represents what is left in the current inner packet being
> > reassembled. When the offset doesn't agree with the known length
> > of the inner being reassembled, the inner is simply dropped and
> > you move to the start of the next packet (which is what the block
> > offset points to).
> >
> > It should be noted that these values are in the cipher text (i.e.
> > they are encrypted inside the ESP wrapper), so getting bad values
> > here is almost for sure due to a bug/corruption on a validated
> > sender rather than an attack. :)
> >
> >
> > Do I understand correctly that the inner packet's native length field
> > is the ground truth, rather than the block offset? I actually don't
> > care how these conflicts are resolved, just that the text resolves
> > them.
>
> That's correct, it's the only place the actual length is, no duplication.
> The block offset always points at the start of the next packet.
>
> From 2.2.1:
>
>Likewise, the
>length of the data block is extracted from the encapsulated IPv4's
>Total Length or IPv6's Payload Length fields.
>
> From 2.2:
>[.. diagram showing "DataBlocks" and "BlockOffset" ..]
>
>If the BlockOffset value is zero it means that the DataBlocks data
>begins with a new data block.
>
>Conversely, if the BlockOffset value is non-zero it points to the
>start of the new data block, and the initial DataBlocks data belongs
>to the data block that is still being re-assembled.
>
>
> > I am not an expert on these attacks, nor do I have a well-thought-out
> > threat model, but IIUC these sorts of problems usually manifest as
> > buffer overflows and the like, not as injected packets. In any case,
> > it's better to have well-defined protocol behavior on unexpected
> > input.
> >
> >
> >
> > > - What if a pad block is in a packet with a BlockOffset greater
> > than the packet
> > > length? Would the receiver skip over the specified bytes in the
> > subsequent
> > > packet, even though padding is supposed to only be at the end
> > of packets?
> >
> > This situation can't occur as pad blocks are very simple and hard
> > to mess up. :) Pad blocks start with 4 0-bits and their length is
> > "the rest of the packet". By definition if the block offset
> > points past the end of the outer packet, there is no pad and the
> > payload is entirely made up of the current inner packet being
> > reassembled.
> >
> >
> > OK. The document seems to define a pad block as a kind of data block,
> > and the BlockOffset field applies to data blocks. So it would be
> > legal to have an all-padding packet with a BlockOffset > outer packet
> > size, IIUC.
>
> No, pad blocks are always from their start to the end of the outer packet.
> You would never be fragmenting (thus "continuing" in the next packet) a pad
> block.
>
> Again from 2.2:
>
>Conversely, if the BlockOffset value is non-zero it points to the
>start of the new data block, and the initial DataBlocks data belongs
>to the data block that is still being re-assembled.
>
> Pad blocks are never fragmented or reassembled.
>
>   From 6.1.3.3: Pad Data Block

[IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-rfc8229bis-07: (with DISCUSS)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-ipsecme-rfc8229bis-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/



--
DISCUSS:
--

Do not panic!

This should be trivial to address, probably by pointing me at something that I
missed (very likely), or by dropping in a sentence to two into the document.

The document starts off with: "This document describes a method to transport
Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection
for traversing network middleboxes that may block IKE negotiation over UDP."

As far as I can tell (and again, it is likely that I missed something!) it
doesn't really discuss the fact that the operator may be intentionally blocking
IKE. For example, many enterprises really don't want their users to be building
IPSec tunnels into/out of their network because they want to do DLP,
firewalling, and so they block IKE to block IPSec. This may be a flawed
concept, and you and I may think that it's a losing battle, but I really think
that the document needs to at least discuss that this potentially bypasses
intentional security controls.

See:
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/





___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Martin Duke's Discuss on draft-ietf-ipsecme-iptfs-13: (with DISCUSS and COMMENT)

[Christian Hopps]

Martin Duke  writes:


Comments inline.

On Tue, Aug 9, 2022 at 8:56 PM Christian Hopps 
wrote:


Thanks for the thorough review! Comments inline..

Martin Duke via Datatracker  writes:

> (6) As malformed packets are sometimes an attack vector, it
would be good to
> specify behavior in response to pathological BlockOffsets, for
instance:
>
> - What if two BlockOffset fields disagree? e.g., with 500 byte
outer packets,
> what if the sequence of block offsets is {0, 750, 100}? Does
the third packet
> have 250 or 100 bytes of the first data block? Drop the packet,
kill the SA,
> ignore one and accept the other, or something else?

The block offset is pointing at the start of the next packet
(which may be beyond the current packets boundary). So it also
represents what is left in the current inner packet being
reassembled. When the offset doesn't agree with the known length
of the inner being reassembled, the inner is simply dropped and
you move to the start of the next packet (which is what the block
offset points to).

It should be noted that these values are in the cipher text (i.e.
they are encrypted inside the ESP wrapper), so getting bad values
here is almost for sure due to a bug/corruption on a validated
sender rather than an attack. :)


Do I understand correctly that the inner packet's native length field
is the ground truth, rather than the block offset? I actually don't
care how these conflicts are resolved, just that the text resolves
them.


That's correct, it's the only place the actual length is, no duplication. The 
block offset always points at the start of the next packet.

From 2.2.1:

  Likewise, the
  length of the data block is extracted from the encapsulated IPv4's
  Total Length or IPv6's Payload Length fields.

From 2.2:
  [.. diagram showing "DataBlocks" and "BlockOffset" ..]

  If the BlockOffset value is zero it means that the DataBlocks data
  begins with a new data block.

  Conversely, if the BlockOffset value is non-zero it points to the
  start of the new data block, and the initial DataBlocks data belongs
  to the data block that is still being re-assembled.



I am not an expert on these attacks, nor do I have a well-thought-out
threat model, but IIUC these sorts of problems usually manifest as
buffer overflows and the like, not as injected packets. In any case,
it's better to have well-defined protocol behavior on unexpected
input.
 


> - What if a pad block is in a packet with a BlockOffset greater
than the packet
> length? Would the receiver skip over the specified bytes in the
subsequent
> packet, even though padding is supposed to only be at the end
of packets?

This situation can't occur as pad blocks are very simple and hard
to mess up. :) Pad blocks start with 4 0-bits and their length is
"the rest of the packet". By definition if the block offset
points past the end of the outer packet, there is no pad and the
payload is entirely made up of the current inner packet being
reassembled.


OK. The document seems to define a pad block as a kind of data block,
and the BlockOffset field applies to data blocks. So it would be
legal to have an all-padding packet with a BlockOffset > outer packet
size, IIUC.


No, pad blocks are always from their start to the end of the outer packet. You would 
never be fragmenting (thus "continuing" in the next packet) a pad block.

Again from 2.2:

  Conversely, if the BlockOffset value is non-zero it points to the
  start of the new data block, and the initial DataBlocks data belongs
  to the data block that is still being re-assembled.

Pad blocks are never fragmented or reassembled.

 From 6.1.3.3: Pad Data Block
1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  0x0  | Padding ...
   +-+-+-+-+-+-+-+-+-+-+-
 Figure 9: Pad Data Block format
  Type:
 A 4-bit value of 0x0 indicating a padding data block.
  Padding:
 Extends to end of the encapsulating packet.


>
--
> COMMENT:
>
--
>
> Thanks to Joe Touch for 2 TSVART reviews, and for addressing
his comments. Also
> thanks for the very literate discussion of congestion control.
>
> (2.2.3) It would be nice to at least suggest a default number
for the
> reordering window. In TCP, we traditionally use 3, but really
any suggestion
> for the clueless is fine.

We could add the text "TCP traditionally uses 3" if you'd like.
:)


Sure.
 


> (3) Please clarify: is TsVal the actual tranmission time, or
the time the
> packet is queued for the next 

Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt

[Michael Richardson]

Robert Moskowitz  wrote:
>> I think it should have public and an errata could be filed for 1-3 ?
>> Or we can draft a separate draft for encoding algo 14 (digital
>> signatures) that also fixes up these entries ?
>>
>> Or this draft could fix them ? Maybe the chairs or AD could give
>> guidance here 


> I think I could have the IANA Considerations have a fix for 1 - 3 as
> well as add 4.

> I will work something up and share it here..

Couldn't the IESG just provide IANA some clarifying guidance here?

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt

[Michael Richardson]

Paul Wouters  wrote:
>> On Aug 10, 2022, at 10:30, Robert Moskowitz 
>> wrote:
>>
>> I will fix my example.  Do you think I should have both examples: with
>> and without gateway?

> No. First because you are not tunneling and it doesn’t apply to you and
> second because it can only be set for IPSECKEY records in the reverse
> zones, not in any forward zones.

Agreed!

>> Per Paul's request I am coming up that for EdDSA I would ask the
>> following be added:
>>
>> 4 An EdDSA Public key is present, in the format defined in [RFC8080]
>> [This]
>>
>>
>> Note the addition of "Public"
>>
>> So should 1 - 3 also have "Public" added?  Should 4 NOT have "Public"
>> Should text be added describing this registry to be for "Public" keys?

> I think it should have public and an errata could be filed for 1-3 ? Or
> we can draft a separate draft for encoding algo 14 (digital signatures)
> that also fixes up these entries ?

I supposed that the word public could be added all over the Registry.
I think that RFC4025 has the word in enough places that it should be obvious
that a private key does not go there.

So this seems like printing "This bag is not a toy" on stuff, but I don't
object to this.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Christian Hopps]

I'll paraphrase what I replied to on the ballot proposal deferment thread:

We designed the encapsulation with IPsec/IP-TFS (IP traffic flow security) in 
mind. This work defines sending fixed-sized packets at a constant rate 
specifically decoupled from the user load to achieve a high degree of traffic 
flow security.

To support fixed-sized packets we have Pad blocks, something that is not 
required for a generic tunnel encapsulation.

We also are replacing the highly inefficient pad mechanism originally defined 
with ESP. To that end we are able to maximize bandwidth by re-using (and 
depending on) the existing ESP sequence number to do things such as reordering 
the outer packet flow to reassemble the inner fragmented packets.

Other parts of this draft deal directly with other security issues such as how 
and when to utilize inner packet IP header values (ECN, DSCP etc.)

If there is a need to have a generic tunneling protocol similar to what we 
have, then the INT area is of course free to borrow from this document in 
creating their own work. However, as noted above we have made specific design 
choices to benefit the intended IPsec/IPTFS use which we have an immediate need 
for, and we would *not* benefit from delaying this work, or making the 
encapsulation more generic.

Thanks,
Chris.

"Eric Vyncke (evyncke)"  writes:


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 tunnel. This smart technique could be use above other
protocols than ESP.



I have just deferred the IESG evaluation of this document to allow
the int-dir and intarea WG to review this document as it has most
probably escaped your filter during the IETF Last Call.



Thank you very much for your comments (please keep all lists in cc)









Regards



-éric





[1] vaguely related to draft-templin-intarea-parcels



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec




signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Martin Duke's Discuss on draft-ietf-ipsecme-iptfs-13: (with DISCUSS and COMMENT)

[Martin Duke]

Comments inline.

On Tue, Aug 9, 2022 at 8:56 PM Christian Hopps  wrote:

>
> Thanks for the thorough review! Comments inline..
>
> Martin Duke via Datatracker  writes:
>
> > (6) As malformed packets are sometimes an attack vector, it would be
> good to
> > specify behavior in response to pathological BlockOffsets, for instance:
> >
> > - What if two BlockOffset fields disagree? e.g., with 500 byte outer
> packets,
> > what if the sequence of block offsets is {0, 750, 100}? Does the third
> packet
> > have 250 or 100 bytes of the first data block? Drop the packet, kill the
> SA,
> > ignore one and accept the other, or something else?
>
> The block offset is pointing at the start of the next packet (which may be
> beyond the current packets boundary). So it also represents what is left in
> the current inner packet being reassembled. When the offset doesn't agree
> with the known length of the inner being reassembled, the inner is simply
> dropped and you move to the start of the next packet (which is what the
> block offset points to).
>
> It should be noted that these values are in the cipher text (i.e. they are
> encrypted inside the ESP wrapper), so getting bad values here is almost for
> sure due to a bug/corruption on a validated sender rather than an attack. :)
>

Do I understand correctly that the inner packet's native length field is
the ground truth, rather than the block offset? I actually don't care how
these conflicts are resolved, just that the text resolves them.

I am not an expert on these attacks, nor do I have a well-thought-out
threat model, but IIUC these sorts of problems usually manifest as buffer
overflows and the like, not as injected packets. In any case, it's better
to have well-defined protocol behavior on unexpected input.


>
> > - What if a pad block is in a packet with a BlockOffset greater than the
> packet
> > length? Would the receiver skip over the specified bytes in the
> subsequent
> > packet, even though padding is supposed to only be at the end of packets?
>
> This situation can't occur as pad blocks are very simple and hard to mess
> up. :) Pad blocks start with 4 0-bits and their length is "the rest of the
> packet". By definition if the block offset points past the end of the outer
> packet, there is no pad and the payload is entirely made up of the current
> inner packet being reassembled.
>

OK. The document seems to define a pad block as a kind of data block, and
the BlockOffset field applies to data blocks. So it would be legal to have
an all-padding packet with a BlockOffset > outer packet size, IIUC.


>
> > --
> > COMMENT:
> > --
> >
> > Thanks to Joe Touch for 2 TSVART reviews, and for addressing his
> comments. Also
> > thanks for the very literate discussion of congestion control.
> >
> > (2.2.3) It would be nice to at least suggest a default number for the
> > reordering window. In TCP, we traditionally use 3, but really any
> suggestion
> > for the clueless is fine.
>
> We could add the text "TCP traditionally uses 3" if you'd like. :)
>

Sure.


>
> > (3) Please clarify: is TsVal the actual tranmission time, or the time the
> > packet is queued for the next transmission opportunity?
>
> It has to be when when queued as the value is set prior to ESP encryption.
>

OK, please clarify in the text.


>
> > (3) This probably just needs a bit more explanation, but reading this
> document,
> > and not knowing much about ESP, I could not figure out the case where the
> > return path does not support AGGFRAG_PAYLOAD. IIUC, IKEv2 negotiates
> this for
> > the pair explicitly, so this case cannot arise. Otherwise, how is this
> > negotiated? Why would a tunnel endpoint support just AGGFRAG without
> payloads
> > but not with?
>
> The most common case (for this admittedly uncommon scenario) would be
> static configuration of the SAs, where only one side is configured to use
> IP-TFS.
>

I guess my confusion is that this case is not about interacting with legacy
devices; they still have to be updated to support AGGFRAG without payloads.
is there
really that big of a win to implement just the headers without supporting
payloads?


>
> > NITS
> > (2.4.1) update the [RFC8229] reference to RFC8229bis?
>
> We wouldn't want to block on this. The normal "updates/replaces" pointers
> should take care of things if/when RFC8229bis gets published, right?
>

The general practice is to prefer the more up-to-date reference, and as
8229bis is going through it shouldn't really block. But I'm not going to
insist.


>
> > (6.1) "The value 5 was chosen to not conflict with other used values."
> IIUC the
> > values here are just Protocol numbers from the registry. So maybe it's
> better
> > to be more explicit and say that this cannot be used with RFC1819
> streams?
>
> They are specific to ESP, but have traditionally been drawn from IP
> protocol 

Re: [IPsec] WGLC of draft-ietf-ipsecme-add-ike

[Tommy Pauly]

I’ve done a review pass of this document. In general, I think it is technically 
good.

I did find several places where I think additional clarity or editorial 
improvements could be made. To address these, I’ve proposed the following pull 
request: https://github.com/boucadair/draft-ietf-ipsecme-add-ike/pull/5

Some of the revenant items I am trying to address are:
- Make it more clear early on that the attributes are generically communicating 
encrypted DNS resolvers, and don’t define specific details for DoH/DoT/DoQ 
(that comes from the SVCB-DNS draft)
- Be more explicit about how ENCDNS_IP* are two specific types, ENCDNS_IP4 and 
ENCDNS_IP6
- Introduce and explain ENCDNS_DIGEST_INFO earlier on. Currently, it is defined 
with no explanation until a later section.
- Clarify the behavior of the initiator for including ENCDNS_IP* attributes. 
Specifically, I believe this is intended to be: either include exactly one 
empty ENCDNS_IP* attribute of a given type to request “any” encrypted DNS 
resolver on that address family; OR, include one or more of that type with 
hints about the addresses and APNs being requested. This was implied by the 
text previously, but not clear.

If these items are addressed, I’m happy to see this progress.

Thanks,
Tommy

> On Aug 9, 2022, at 1:47 PM, Tero Kivinen  wrote:
> 
> This is the start of 2 week WGLC on the document, ending 2022-08-17.
> Please submit your comments to the list, also send a note if you have
> reviewed the document, so we can see how many people are interested in
> getting this out.
> -- 
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Can you review draft-ietf-ipsecme-iptfs as it is about tunnels

[Eric Vyncke (evyncke)]

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 tunnel. This smart 
technique could be use above other protocols than ESP.

I have just deferred the IESG evaluation of this document to allow the int-dir 
and intarea WG to review this document as it has most probably escaped your 
filter during the IETF Last Call.

Thank you very much for your comments (please keep all lists in cc)

Regards

-éric


[1] vaguely related to draft-templin-intarea-parcels
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt

[Robert Moskowitz]

Paul,


On 8/10/22 11:09, Paul Wouters wrote:



On Aug 10, 2022, at 10:30, Robert Moskowitz  
wrote:


I will fix my example.  Do you think I should have both examples: 
with and without gateway?


No. First because you are not tunneling and it doesn’t apply to you 
and second because it can only be set for IPSECKEY records in the 
reverse zones, not in any forward zones.




Current IANA registry is:

0     No key is present     [RFC4025]
1     A DSA key is present, in the format defined in [RFC2536]     
[RFC4025]
2     A RSA key is present, in the format defined in [RFC3110]     
[RFC4025]
3     An ECDSA key is present, in the format defined in [RFC6605]     
[RFC8005]



Per Paul's request I am coming up that for EdDSA I would ask the 
following be added:


4 An EdDSA Public key is present, in the format defined in 
[RFC8080]   [This]



Note the addition of "Public"

  * So should 1 - 3 also have "Public" added?
  * Should 4 NOT have "Public"
  * Should text be added describing this registry to be for "Public"
keys?

I think it should have public and an errata could be filed for 1-3 ? 
Or we can draft a separate draft for encoding algo 14 (digital 
signatures) that also fixes up these entries ?


Or this draft could fix them ? Maybe the chairs or AD could give 
guidance here 



I think I could have the IANA Considerations have a fix for 1 - 3 as 
well as add 4.


I will work something up and share it here..





Thanks Bob!

Paul


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt

[Paul Wouters]

> On Aug 10, 2022, at 10:30, Robert Moskowitz  wrote:
> 
> I will fix my example.  Do you think I should have both examples: with and 
> without gateway?

No. First because you are not tunneling and it doesn’t apply to you and second 
because it can only be set for IPSECKEY records in the reverse zones, not in 
any forward zones.


> Current IANA registry is:
> 
> 0 No key is present [RFC4025]
> 1 A DSA key is present, in the format defined in [RFC2536] [RFC4025]
> 2 A RSA key is present, in the format defined in [RFC3110] [RFC4025]
> 3 An ECDSA key is present, in the format defined in [RFC6605] 
> [RFC8005]
> 
> 
> Per Paul's request I am coming up that for EdDSA I would ask the following be 
> added:
> 
> 4 An EdDSA Public key is present, in the format defined in [RFC8080]   
> [This]
> 
> 
> Note the addition of "Public"
> 
> So should 1 - 3 also have "Public" added?
> Should 4 NOT have "Public"
> Should text be added describing this registry to be for "Public" keys?
I think it should have public and an errata could be filed for 1-3 ? Or we can 
draft a separate draft for encoding algo 14 (digital signatures) that also 
fixes up these entries ?

Or this draft could fix them ? Maybe the chairs or AD could give guidance here 


Thanks Bob!

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt

[Robert Moskowitz]

Tero,

Thanks for the review.

On 8/9/22 11:46, Tero Kivinen wrote:

Robert Moskowitz writes:

This latest ver is in response to comments recieved.

Please review Appendix A that I have the RR properly set up.

I think the priority needs to be in decimal, and you are missing the
gateway address. I.e., at least the 4025 has examples as follows:

38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2
 192.0.2.38
 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )

where you have:

foo.example.com IN IPSECKEY
   (a 0 4 3WTXgUvpn1RlCXnm80gGY2LZ/ErUUEZtZ33IDi8yfhM= )

The generic format from 4025 is:

IN IPSECKEY ( precedence gateway-type algorithm
  gateway base64-encoded-public-key )

and also says:

If no gateway is to be indicated, then the gateway type field MUST be
zero, and the gateway field MUST be "."


I missed that in my read of 4025.


So I think the correct example should be:

foo.example.com IN IPSECKEY
   (10 0 4 . 3WTXgUvpn1RlCXnm80gGY2LZ/ErUUEZtZ33IDi8yfhM= )


I will fix my example.  Do you think I should have both examples: with 
and without gateway?





I also have questions about the text added to specify this is for public key
lookup.  Please review how I have said this in the draft.

Also the text for use in the IPSECKEY registry is at odds with the text for
the current values.  What to do?

Instruct IANA to adjust the text for values 1 - 3 to match?

What do you mean with this?


Current IANA registry is:

0     No key is present     [RFC4025]
1     A DSA key is present, in the format defined in [RFC2536] [RFC4025]
2     A RSA key is present, in the format defined in [RFC3110] [RFC4025]
3     An ECDSA key is present, in the format defined in [RFC6605]     
[RFC8005]



Per Paul's request I am coming up that for EdDSA I would ask the 
following be added:


4 An EdDSA Public key is present, in the format defined in 
[RFC8080]   [This]



Note the addition of "Public"

 * So should 1 - 3 also have "Public" added?
 * Should 4 NOT have "Public"
 * Should text be added describing this registry to be for "Public" keys?


Choise one (I hope!)


Write text to go at the beginning that this is for public keys and remove the
proposed such text for the eddsa value.  I have not (yet) found any IANA
registry that has such text, and any points would help this discussion.



Bob
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Martin Duke's No Objection on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

[Martin Duke]

Sounds good to me, we're all set modulo the thread with Joe.

On Wed, Aug 10, 2022, 01:25 Valery Smyslov  wrote:

> Hi Martin,
>
>
>
> please see inline.
>
>
>
> On Mon, Aug 8, 2022 at 5:12 AM Valery Smyslov  wrote:
>
> >
> > (Sec 9.1)
> > "TCP-in-TCP can also lead to "TCP meltdown", where stacked instances
> >of TCP can result in significant impacts to performance
> >[TCP-MELTDOWN].  For the case in this document, such meltdown can
> >occur when the window size of the outer TCP connection is smaller
> >than the window sizes of the inner TCP connections.  The resulting
> >interactions can lead to packets backing up in the outer TCP
> >connection's send buffers.  In order to limit this effect, the outer
> >TCP connection should have limits on its send buffer size and on the
> >rate at which it reduces its window size."
> >
> > Which "window" are you referring to? Receive window, congestion window,
> > or the
> > send buffer? My reading of [TCP-MELTDOWN] is that the tunnel ingress
> > should set
> > its send buffer size to the BDP of the tunnel, which is easier said than
> done.
> > It appears you are using "window" and "send buffer" interchangeably here
> in a
> > way that is confusing.
>
> This text was suggested by Joe Touch (
> https://mailarchive.ietf.org/arch/msg/ipsec/eD85hixrzfqwg4UhwRZ8WL5PkDA/)
> If you think it is unclear, can you please suggest how it can be improved?
>
>
>
> OK, I'll start a separate thread with Joe and you.
>
>
>
>   OK, thank you.
>
>
>
>
> > (9.5)
> > Implementations SHOULD follow the ECN compatibility mode for tunnel
> >ingress as described in [RFC6040].  In compatibility mode, the outer
> >tunnel TCP connection marks its packet headers as not ECN-capable.
> >If upon egress, the arriving outer header is marked with CE, the
> >implementation will drop the inner packet, since there is not a
> >distinct inner packet header onto which to translate the ECN
> >markings.
> >
> > This is not an accurate summary of compatibility mode. In compatibility
> mode,
> > the outer packet is marked Not-ECT, which means it will not be marked
> CE. In
> > normal mode, the outer packet is marked as the inner, and this might
> result in
> > an outer CE marking.
>
> Can you please, clarify why the description is inaccurate?
>
> According to RFC 6040 in compatibility mode outer packet are marked as not
> ECN-capable
> (Not-ECT). On the other hand, since using compatibility mode is SHOULD here
> and currently it is assumed that IPsec tunnels are used with normal mode
> (RFC 4301, RFC 6040), then some
> additional guidelines are given what to do if peer still uses normal mode.
>
> Am I missing something?
>
>
>
> I think my confusion here was that I read the second sentence ("If upon
> egress...") as also describing RFC6040,
>
> which I see now it does not. My apologies; perhaps splitting it into two
> paragraphs would help. However, the need
>
> for this text is related to difficulty mapping outer to inner; see also
> below.
>
>
>
>   I moved this sentence to a new paragraph.
>
>
>
>
> > It's a shame that there is no attempt to figure out a mapping between
> inner
> > and
> > outer that would make normal mode work, as this reviewer is optimistic
> that
> > ECN
> > marks will become increasingly important. But regardless, this section
> should
> > be clear and make correct statements.
>
> I'm not sure this is generally possible given that one outer TCP tunnel
> can include many inner TCP tunnels, so you have to decide which
> of them to inform. The things get worse if AggFrag mechanism
> is in use (draft-ietf-ipsecme-iptfs-13, in IESG evaluation).
>
>
>
> This isn't a DISCUSS, so you can choose to ignore this advice or not.
> However, my concern is that IPSec is going to miss
>
> out on the low-latency services operators are now enabling through ECN.
>
>
>
>   Not exactly :-) Note, that TCP is not a default transport for
> IPsec
>
>   and in case ESP is sent over IP or UDP, all the modern ECN
>
>   techniques must work well (I guess you mean L4S networks?).
>
>   TCP is a backup transport in case no other is available and
>
>   due to the inherent problems (TCP-in-TCP) we don't expect
>
>   to get good performance in this case, so there is no point
>
>   to complicate the protocol. TCP encapsulation is for those cases
>
>   when you need things to work somehow, not in the best way.
>
>
>
> If it were me I would design it this way:
>
>
>
> 1) Encapsulators SHOULD NOT mix ECT(0), Not-ECT, and ECT(1) inner packets
> in the same outer packet.
>
> 2) If they do, the outer packet MUST be marked Not-ECT.
>
> 3) If all packets are marked CE, mark the outer packet CE.
>
> 4) If CE packets are mixed with "something else", mark it "something else".
>
> 5) Decapsulators follow Figure 4 in RFC6040, except they SHOULD NOT log an
> event or raise an alarm when
>
> the outer packet 

Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

[Valery Smyslov]

Hi Paul,

thank you for the very thorough review (as usual) :-). Please see inline.

> Paul Wouters has entered the following ballot position for
> draft-ietf-ipsecme-rfc8229bis-07: Yes
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-
> ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/
> 
> 
> 
> --
> COMMENT:
> --
> 
> # SEC AD comments for draft-ietf-ipsecme-rfc8229bis-07
> CC @paulwouters
> 
> 
> ## Comments
> 
> I have a number of comments and some small fixes. While the appendix fixes
> technically
> might be a DISCUSS, I have faith the authors will pick it up from the comment
> section too :)

Sure :-)

> ###
> 
> The Length field plus non-ESP marker plus IKE packet is called "message"
> at the start in Section 3, but in Section 3.1 it is called an "IKE Header 
> Format"
> and "IKE message" is used to denote the non-ESP marker plus IKE Header
> _without_
> the Length field. And then it uses "IKE Packet" in the Length field 
> description to
> mean the thing without the Length and non-esp marker. And then the figure
> uses
> "IKE header" were it should probably say "IKE packet".
> 
> These names should be made more consistent :)

I agree that there is some mess in using different terms (message, packet etc.).
Most of this mess was in RFC 8229 and we tried to keep the text when possible.
Those cases, while formally not accurate, didn't cause confusion (in our 
opinion), so no attempts 
to fix them were done (note, that similar mess exists in RFC 7296 as a leftover 
from 5996 and 4306,
and at the time 7296 was being developed my attempts to fix some terms were 
rejected
by the WG with the resolution - those places never caused confusion, so let 
them be :-)).

That being said, I think that we can fix at least some of these discrepancies.

So, I've change in sections 3.1 and 3.2:

s/IKE Header/IKE Message
s/ESP Header/ESP Packet

including titles and figures.

> ###
> 
> Section 3.1 and Section 3.2 state:
> 
> The value in the Length field MUST NOT be 0 or 1.
> 
> In fact, a lot more values are clearly wrong, like anything
> under 4 which cannot contain the non-esp marker. Then there
> is the size of the minimum UDP IKE or ESP packet as well.
> Why are these two values singled out?

Because only these two values don't allow to continue parsing the TCP stream
(to find the next Length field in the stream).

We try to keep layer separation here - obviously, the content of the packets
may be malformed, but it is checked by another layer. The checks you described
are identical for both UDP and TCP encapsulation and are not specific for this 
draft.

BTW, the value 3 for the Length field is valid, even if it is under 4  :-) - 
in case of NAT keepalive packet (discouraged, but not prohibited over TCP).

> ###
> 
> Section 3.1 states:
> 
> The IKE header is preceded by a 16-bit Length field in network byte
> order that specifies the length of the IKE message
> 
> Section 3.2 states:
> 
> The ESP header is preceded by a 16-bit Length field in network byte
> order that specifies the length of the ESP packet
> 
> Why don't both say either "message" or "packet"? I would say "packet" for
> both.

As I said there is a little mess, but traditionally we use in IPsec terms "IKE 
message"
and "ESP packet". "IKE packet" is also used but somehow rarely. We just try to 
follow
this tradition :-)

> ###
> 
> Section 4:
> 
> at the beginning of any stream of IKE and ESP messages.
> 
> I would s/any/the TCP/ to avoid people thinking of the inner streams and
> thinking
> they need to repeat the IKETCP prefix for each burst of traffic - this mistake
> was
> made once in the first version of the Linux kernel code.

OK, changed.

> ###
> 
> Section 5:
> 
> when it has been configured to be used with specific IKE peers.
> 
> I would say "when it has been configured to be optionally used with specific
> IKE peers.
> Otherwise, implementers might think it needs to be an on/off setting instead
> of a
> "may be used when udp is blocked" setting.

Well, I think these implementation details need not to be covered in the spec.
While UDP is preferred, there may be situations, where it is known for sure
that UDP is permanently blocked, so there is no need to try it each time 
introducing additional delay.
For example, our implementations may be configured with three choices (per 
peer) - 
never use TCP, may use TCP if UDP is blocked, always use TCP.

I'd 

[IPsec] I-D Action: draft-ietf-ipsecme-yang-iptfs-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions WG of 
the IETF.

Title   : A YANG Data Model for IP Traffic Flow Security
Authors : Don Fedyk
  Christian Hopps
  Filename: draft-ietf-ipsecme-yang-iptfs-07.txt
  Pages   : 28
  Date: 2022-08-10

Abstract:
   This document describes a yang module for the management of IP
   Traffic Flow Security additions to IKEv2 and IPsec.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-yang-iptfs/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-yang-iptfs-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-yang-iptfs-07


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Éric Vyncke's Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

[Eric Vyncke (evyncke)]

Goedendag Paul, ;-)

Thank you for your reply, Valery has also replied to my comments (and I agree 
with Valery's reply).

Have a look below for EV>

Regards

-éric



On 10/08/2022, 02:40, "Paul Wouters"  wrote:

On Tue, 9 Aug 2022, Éric Vyncke via Datatracker wrote:

> ### Section 3 No AH
>
> Even if AH is nearly no more used, I wonder whether there is a reason why 
AH is
> not supported by this I-D.

Because we dont wants it :)

EV> I can understand ;-)

RFC 3948 also only defines ESPinUDP and not AHinUDP.

EV> ack, it does make sense that this I-D does not cover it

> ### Section 3
>
> ```
>   Although a TCP stream may be able to send very long messages,
>   implementations SHOULD limit message lengths to typical UDP datagram
>   ESP payload lengths.
> ```
>
> What is the 'typical' length ?

slightly under 1500?

EV> or 1280 for IPv6 ? Valery has suggested good text because 'typical' means 
nothing

> ### Section 5.1
>
> `Since UDP is the preferred method of transport for IKE messages,` hem...
> previous text (and common sense) stated that direct is the preferred 
method.

Direct is UDP, as UDP is the native IKE transport.

EV> shame on me...

> ### Section 6.1 what about IP address changes ?
>
> ```
>   Since new TCP connections
>   may use different ports due to NAT mappings or local port allocations
>   changing, the TCP Responder MUST allow packets for existing SAs to be
>   received from new source ports.
> ```
> For some NAT devices (or IPv6 nodes w/o NAT but with temporary 
addresses), the
> IP address could also change. This document should describe what to do in 
this
> case.

The IP address cannot just change mid-stream for TCP as it can for UDP.
It would have to be a new TCP stream and those cases are described in
the document.

> Please add that the DF bit is obvioulsy only for IPv4 (Hi, Tommy, I had to
> insert my mandatory IPv6-related comment ;-) )

:) Perhaps we can add a comment about NAT for IPv6 not being implemented
in Linux (or did they finally do it? :)

EV> __ how do you dare ! 
EV> more seriously, Valery's new text is good for me

Left other items to the actual authors :)

EV> always nice to see an AD interested deeply in an I-D

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Éric Vyncke's Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

[Eric Vyncke (evyncke)]

Hello Valery,

Thanks again for the discussion, it should help improving the I-D.

Look below for EV2>

Cheers

-éric

On 09/08/2022, 18:03, "Valery Smyslov"  wrote:

Éric, please see my comments below.
For readability I removed some of the stuff we agreed upon.

> Hello Valery,
> 
> Thank you for the prompt reply.
> 
> It looks like Erik Kline could be my twin brother as we often emit the 
same
> comments. FYI, I never read other ADs' ballot to avoid being biased.
> 
> I agree with all your replies and explanations except when there is EV>
> 
> Regards
> 
> -éric
> 
> 
> On 09/08/2022, 15:59, "Valery Smyslov"  wrote:
> 
> Hi Éric,
> 
> thank you for your comments. Please see inline.
> 
> > Éric Vyncke has entered the following ballot position for
> > draft-ietf-ipsecme-rfc8229bis-07: Yes
> >
> > When responding, please keep the subject line intact and reply to 
all email
> > addresses included in the To and CC lines. (Feel free to cut this
> introductory
> > paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-
> > ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT
> positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/
> >
> >
> >
> > 
--
> > COMMENT:
> > 
--
> >
> > # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-rfc8229bis-07
> > CC @evyncke
> >
> > Thank you for the work put into this document. There must be 
several use
> > cases
> > for it.
> >
> > Please find below some non-blocking COMMENT points (but replies 
would
> be
> > appreciated even if only for my own education).
> >
> > Special thanks to Tero Kivinen for the shepherd's detailed write-up
> including
> > the WG consensus, but it lacks the justification of the intended 
status.
> >
> > Thanks as well to Brian Haberman for his INT directorate review, 
his review
> has
> > a 'ready' status.
> >
> > I hope that this review helps to improve the document,
> >
> > Regards,
> >
> > -éric
> >

[snip]

> > ### Section 3
> >
> > ```
> >Although a TCP stream may be able to send very long messages,
> >implementations SHOULD limit message lengths to typical UDP 
datagram
> >ESP payload lengths.
> > ```
> >
> > What is the 'typical' length ?
> 
> It's usually the size of PMTU.
> 
> EV> then it is worth mentioning

I'd rather to change the whole sentence:

Current:
   Although a TCP stream may be able to send very long messages,
   implementations SHOULD limit message lengths to typical UDP datagram
   ESP payload lengths.

Proposed:
   Although a TCP stream may be able to send very long messages,
   implementations SHOULD limit message lengths as if UDP encapsulation of 
ESP is used.

Thus we eliminate the word "typica", which is problematic, and keep the 
idea - 
don't send very long messages with TCP encapsulation.

Are you OK with this?

EV2> this is good enough for me (the 'typical' was not explained hence my 
concern)

> > ### Section 6.1 what about IP address changes ?
> >
> > ```
> >Since new TCP connections
> >may use different ports due to NAT mappings or local port 
allocations
> >changing, the TCP Responder MUST allow packets for existing SAs 
to be
> >received from new source ports.
> > ```
> > For some NAT devices (or IPv6 nodes w/o NAT but with temporary
> addresses),
> > the
> > IP address could also change. This document should describe what to 
do in
> this
> > case.
> 
> The responder may have policy restricting source IP addresses. The 
whole
> point
> of this text is that it should not restrict source ports, with TCP 
they are
> usually ephemeral.
> 
> EV> then, would the document benefit with some text around "TCP responder
> MAY allow packets for existing SAs to be received from new IP addresses" ?

How about:

Current:
   Since new TCP connections
   may use different ports due to NAT mappings or local port allocations
   changing, the TCP Responder MUST allow packets for existing SAs to be
   received from 

Re: [IPsec] Martin Duke's No Objection on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

[Valery Smyslov]

Hi Martin,

 

please see inline.

 

On Mon, Aug 8, 2022 at 5:12 AM Valery Smyslov <  
s...@elvis.ru> wrote:

> 
> (Sec 9.1)
> "TCP-in-TCP can also lead to "TCP meltdown", where stacked instances
>of TCP can result in significant impacts to performance
>[TCP-MELTDOWN].  For the case in this document, such meltdown can
>occur when the window size of the outer TCP connection is smaller
>than the window sizes of the inner TCP connections.  The resulting
>interactions can lead to packets backing up in the outer TCP
>connection's send buffers.  In order to limit this effect, the outer
>TCP connection should have limits on its send buffer size and on the
>rate at which it reduces its window size."
> 
> Which "window" are you referring to? Receive window, congestion window,
> or the
> send buffer? My reading of [TCP-MELTDOWN] is that the tunnel ingress
> should set
> its send buffer size to the BDP of the tunnel, which is easier said than done.
> It appears you are using "window" and "send buffer" interchangeably here in a
> way that is confusing.

This text was suggested by Joe Touch 
(https://mailarchive.ietf.org/arch/msg/ipsec/eD85hixrzfqwg4UhwRZ8WL5PkDA/)
If you think it is unclear, can you please suggest how it can be improved?

 

OK, I'll start a separate thread with Joe and you.

 

  OK, thank you.

 


> (9.5)
> Implementations SHOULD follow the ECN compatibility mode for tunnel
>ingress as described in [RFC6040].  In compatibility mode, the outer
>tunnel TCP connection marks its packet headers as not ECN-capable.
>If upon egress, the arriving outer header is marked with CE, the
>implementation will drop the inner packet, since there is not a
>distinct inner packet header onto which to translate the ECN
>markings.
> 
> This is not an accurate summary of compatibility mode. In compatibility mode,
> the outer packet is marked Not-ECT, which means it will not be marked CE. In
> normal mode, the outer packet is marked as the inner, and this might result in
> an outer CE marking.

Can you please, clarify why the description is inaccurate?

According to RFC 6040 in compatibility mode outer packet are marked as not 
ECN-capable
(Not-ECT). On the other hand, since using compatibility mode is SHOULD here
and currently it is assumed that IPsec tunnels are used with normal mode (RFC 
4301, RFC 6040), then some 
additional guidelines are given what to do if peer still uses normal mode.

Am I missing something?

 

I think my confusion here was that I read the second sentence ("If upon 
egress...") as also describing RFC6040,

which I see now it does not. My apologies; perhaps splitting it into two 
paragraphs would help. However, the need

for this text is related to difficulty mapping outer to inner; see also below.

 

  I moved this sentence to a new paragraph.

 


> It's a shame that there is no attempt to figure out a mapping between inner
> and
> outer that would make normal mode work, as this reviewer is optimistic that
> ECN
> marks will become increasingly important. But regardless, this section should
> be clear and make correct statements.

I'm not sure this is generally possible given that one outer TCP tunnel
can include many inner TCP tunnels, so you have to decide which 
of them to inform. The things get worse if AggFrag mechanism
is in use (draft-ietf-ipsecme-iptfs-13, in IESG evaluation).

 

This isn't a DISCUSS, so you can choose to ignore this advice or not. However, 
my concern is that IPSec is going to miss

out on the low-latency services operators are now enabling through ECN.

 

  Not exactly :-) Note, that TCP is not a default transport for IPsec

  and in case ESP is sent over IP or UDP, all the modern ECN 

  techniques must work well (I guess you mean L4S networks?).

  TCP is a backup transport in case no other is available and

  due to the inherent problems (TCP-in-TCP) we don't expect

  to get good performance in this case, so there is no point

  to complicate the protocol. TCP encapsulation is for those cases

  when you need things to work somehow, not in the best way.

 

If it were me I would design it this way:

 

1) Encapsulators SHOULD NOT mix ECT(0), Not-ECT, and ECT(1) inner packets in 
the same outer packet.

2) If they do, the outer packet MUST be marked Not-ECT.

3) If all packets are marked CE, mark the outer packet CE.

4) If CE packets are mixed with "something else", mark it "something else".

5) Decapsulators follow Figure 4 in RFC6040, except they SHOULD NOT log an 
event or raise an alarm when

the outer packet is ECT(1) and one of the inner packets is CE.

 

Per 3168, if an inner packet is fragmented, any CE applied to a fragment is 
applied to the reassembled packet.

 

  This might work, but please, see above.

 


> (Appendix A) Why not provide an in-band way to determine TLS support?
>