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

["Hamilton, Robert" <[e-mail]>]

Paolo:

I'm particularly interested in PDM for helping with Enterprise Extender connections. Since we  are using the internet for these connections we are subject to the vagaries of ISP traffic management and outages on multiple continents. It's not just multinational companies that could make good use of this protocol, but any companies with business partners with whom they require reliable internet connectivity. In those cases I expect the end-node encryption is a relatively smaller portion of the total packet transmission time.

I don't want to slow down the PDM implementation, and in general I think the encryption is a good idea. Encryption is fast on this platform, but to my knowledge it doesn't do HPKE. I've just looked through the RFE site and haven't seen any asking for HPKE support.

Getting good value from PDM requires that destination headers be passed reliably from end to end. We probably have to lobby for that first, good extension header handling network-wide. I'll be happy when I see PDM headers show up in my Policy Agent logs.

R;


Rob Hamilton
Infrastructure Engineer
Chemical Abstracts Service

-----Original Message-----
From: ippm <[e-mail]> On Behalf Of Paolo Volpato
Sent: Friday, July 2, 2021 10:26 AM
To: [e-mail]
Cc: [e-mail]; IETF IPPM WG <[e-mail]>
Subject: [EXT] Re: [ippm] Fw: New Version Notification for draft-elkins-ippm-encrypted-pdmv2-00.txt

[Actual Sender is [e-mail]]

Hi Nalini,

Thanks for advising.

I have a couple of general questions.

At a first glance, it seems to me that PDMv2 is expected to be used mainly in the enterprise domain. Is it so? 
Do you have any thoughts on what may happen if e.g. a multinational company runs the protocol over multiple external backbones where the IPv6 extension headers (in general, not necessarily just the destination options header) may not be handled? Does this represent a serious issue?

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?

Regards
Paolo

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

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=ae63ba6f-614c-40c5-9a6d-dbc4bc0fbb82&auth=3c97381e9a30865a1a3f3ad58750d85b2b059558-117b9ada8970552b00544efe952da754c5c92078
[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=ae63ba6f-614c-40c5-9a6d-dbc4bc0fbb82&auth=3c97381e9a30865a1a3f3ad58750d85b2b059558-117b9ada8970552b00544efe952da754c5c92078
[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
_______________________________________________
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.