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

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] 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] 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

[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