Re: [ippm] Fw: New Version Notification for draft-elkins-ippm-encrypted-pdmv2-00.txt

[Ameya Deshpande <[e-mail]>]

 Hi Paolo,
Thanks for your comments. Please check the inline reply.
> Also,  I assume that PDMv2 is mainly used by end stations (e.g. hosts instead of routers). If this is the case, then I don’t expect that the performance degradation due to encryption is a serious issue. Do you see other different cases where instead degradation may be a concern? 

When using encrypted PDMv2, we have a bigger packet to send asthe size of encrypted data is more than the corresponding plaintext data.This can increase the timing slightly as the packet size has increased.

For using encrypted PDMv2, we have an initial registration phase wherewe negotiate the shared secret (using KEM). We have also given a registrationmechanism for enterprises with many servers and clients. However, this willbe done before transmitting PDMv2 packets.
We intend to have a side-meeting where we will explain HPKE and be able to thoroughly discuss these points.  When we are able to schedule it, we will let you know.  The registration to schedule side meetings has not yet opened.
Thanks,Ameya Deshpande
    On Monday, 5 July, 2021, 10:19:21 pm IST, Ameya Deshpande <ameyanrd=[e-mail]> wrote:  
 
  Hi Robert,
Thanks for your comments. Please check the inline comments.
> - The latest HPKE draft expired just last week. That means it's some time before general implementation. I'm a mainframer, mostly, so I suspect that makes it even longer before I'll see implementation for _production_ use. Further, I don't want the implementation of PDM in more secure environments delayed because of encryption-method concerns. 

We have kept an option for no-encryption in PDMv2 as well. And it is kept exactly for
 the same reason you mentioned. Connections over encrypted medium (say VPN tunnels),link-local network, or any secured company domain can choose to use PDMv2 unencrypted.
> - When we generate the PDM structure and determine the timing, we want that to be as close to the wire as possible. The PDM timing was very granular, so this will add a variable amount of time to the time the packet is determined to be spending in transmission; the encryption delay is now part of the transmission time.
Yes, for a PDM-to-PDM machine, the round trip time, a.k.a DELTATLS, will include the two encryptionand two decryption times. We are trying our best to minimize any added timing due to the encryption in PDMv2, but we feel that encryption is important, so we're trying to achieve a correct balance.
Thanks,Ameya Deshpande

    On Monday, 5 July, 2021, 9:57:51 pm IST, [e-mail] <[e-mail]> wrote:  
 
 Hi Robert,[Posting for some of the co-authors.]We fully agree with your concerns. However, we’re confident that HPKE will reach the RFC status soon. Moreover, also other protocols (e.g., MLS, see https://www.ietf.org/archive/id/draft-ietf-mls-architecture-06.txt) are using it.About HPKE itself, there are two different aspects to consider: HPKE (as an architecture, API, etc.) and the cryptographic functions used by HKPE. While HPKE is still in draft, the cryptographic functions are well-known and proven. Hence, we don’t expect any concern related to the encryption methods used by HPKE.The fact that Tommy confirms that it is being implemented and deployed reinforces our confidence on the fact that its availability is not going to be a critical point.
In any case, we will take this point into consideration, as it is a valid concern.
Best regards,
Nalini, Tom, and Adnan
  

    On Thursday, July 1, 2021, 02:05:31 PM PDT, Hamilton, Robert <rhamilton=[e-mail]> wrote:  
 
 I am interested in the encryption of the PDM header, just because I've done symmetric-key encryption with pseudorandom numbers and pseudorandom obfuscation algorithms for key management. I see that we are interested in using HPKE. I have just a few concerns:

 - The latest HPKE draft expired just last week. That means it's some time before general implementation. I'm a mainframer, mostly, so I suspect that makes it even longer before I'll see implementation for _production_ use. Further, I don't want the implementation of PDM in more secure environments delayed because of encryption-method concerns.

 - When we generate the PDM structure and determine the timing, we want that to be as close to the wire as possible. The PDM timing was very granular, so this will add a variable amount of time to the time the packet is determined to be spending in transmission; the encryption delay is now part of the transmission time.

Still reviewing; I'll be back with more thoughts.

R;


Rob Hamilton
Infrastructure Engineer
Chemical Abstracts Service

-----Original Message-----
From: ippm <[e-mail]> On Behalf Of [e-mail]
Sent: Thursday, July 1, 2021 1:45 PM
To: IETF IPPM WG <[e-mail]>
Cc: [e-mail]
Subject: [EXT] Re: [ippm] Fw: New Version Notification for draft-elkins-ippm-encrypted-pdmv2-00.txt

[Actual Sender is [e-mail]]

IPPM,

Please do take a look at this draft.

I think that iOAM will need encryption as well.   We have spent quite a bit of time thinking over these issues.  We even have 2 cryptographers from Italy involved as co-authors.   I want to do a side meeting where we can have quite a bit more time to discuss this but would love to have comments from the group on the list.

I am very reluctant to push PDM out to the wider world without encryption.  I feel that we will become the attacker's best friend.
We have modified the Linux kernel to include PDM but as I say, without encryption, we do not wish to release.


Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=www.insidethestack.com&umid=61654d20-9615-453c-80b2-c06c82268e9d&auth=3c97381e9a30865a1a3f3ad58750d85b2b059558-86a3cb083390e2163fd0daaf45646c2a55adf702
[phone]






On Tuesday, June 1, 2021, 09:06:39 AM PDT, [e-mail] <[e-mail]> wrote: 





Hello IPPMers!

We have just posted a new draft to encrypt PDM data.   We feel that this is an important feature to add before promoting widespread adoption of PDM.

We would appreciate any thoughts or comments from the group.

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=www.insidethestack.com&umid=61654d20-9615-453c-80b2-c06c82268e9d&auth=3c97381e9a30865a1a3f3ad58750d85b2b059558-86a3cb083390e2163fd0daaf45646c2a55adf702
[phone]






----- Forwarded Message -----

From: "[e-mail]" <[e-mail]>
To: [e-mail] <[e-mail]>; Adnan Rashid <[e-mail]>; Ameya Deshpande <[e-mail]>; Michael Ackermann <[e-mail]>; Nalini Elkins <[e-mail]>; Tommaso Pecorella <[e-mail]>
Sent: Tuesday, June 1, 2021, 12:01:47 PM EDT
Subject: New Version Notification for draft-elkins-ippm-encrypted-pdmv2-00.txt



A new version of I-D, draft-elkins-ippm-encrypted-pdmv2-00.txt
has been successfully submitted by Nalini Elkins and posted to the
IETF repository.

Name:        draft-elkins-ippm-encrypted-pdmv2
Revision:    00
Title:        Encrypted IPv6 Performance and Diagnostic Metrics Version 2 (EPDMv2) Destination Option
Document date:    2021-06-01
Group:        Individual Submission
Pages:        16
URL:            https://www.ietf.org/archive/id/draft-elkins-ippm-encrypted-pdmv2-00.txt
Status:        https://datatracker.ietf.org/doc/draft-elkins-ippm-encrypted-pdmv2/
Htmlized:      https://datatracker.ietf.org/doc/html/draft-elkins-ippm-encrypted-pdmv2


Abstract:
  RFC8250 describes an optional Destination Option (DO) header embedded
  in each packet to provide sequence numbers and timing information as
  a basis for measurements.  As this data is sent in clear- text, this
  may create an opportunity for malicious actors to get information for
  subsequent attacks.  This document defines PDMv2 which has a
  lightweight handshake (registration procedure) and encryption to
  secure this data.  Additional performance metrics which may be of use
  are also defined.

                                                                                  


The IETF Secretariat




_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm
Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from CAS, a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.
_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm
  _______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm
  _______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm