[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PROTO-17: Encrypted Packets + PROTO-106: extend security considerations on exported Payload



Benoit,

I support this solution for PROTO-17.

I also support the intention behind the suggested text
that addresses PROTO-106.  But I do not see how it would be
realized.  How would an implementation ensure that it does
not export the full payload of a conversation?

Thanks,

   Juergen

--On 3/2/06 4:41 PM +0100 Benoit Claise wrote:

Dear all,


The two issues we must be fixing are:

 PROTO-17 "Encrypted Packets: Selectors that interpret packet fields
   must be configurable to ignore (i.e. not select) encrypted packets,
   when they are detected". "Since packet encryption alters the meaning
   of encrypted fields, field match filtering must be configurable to
   ignore encrypted packets, when detected." I guess we will need extra
   text for this.

 PROTO-106 Extend security considerations by a discussion on exported
   Payload. Consider whether [PSAMP-INFO] or [PSAMP-PROTO] or both
   is/are the place(s).



[CHARTER] says:





Selection of the content of packet reports will be cognizant of privacy and anonymity issues while being responsive to the needs of measurement applications, and in accordance with RFC 2804.



[RFC3917] says:



4.1. Encryption

If encryption is used, the metering process might not be able to
access all header fields. A metering process must meet the
requirements stated in this section 4 only for packets that have the
relevant header fields not encrypted.




[PSAMP-PROTO] says:



8 Security Considerations

As IPFIX has been selected as the PSAMP export protocol and as
the PSAMP security requirements are not stricter than the IPFIX security
requirements, refer to the IPFIX export protocol [IPFIX-PROTO] for the security
considerations.





So what to write? Hereafter a few proposal

- in Property Match Filtering section, I would add:





"Since encryption alters the meaning of encrypted fields, when the Property Match Filtering classification is based on the encrypted field(s) in the packet, it MUST be able to recognize that the field(s) are not available and not select those packets.
Even if they are ignored, the encrypted packets MUST be accounted in the Selector packetObserved Information Element [PSAMP-INFO], part of the Selection Sequence Statistics Report Interpretation."



- in Hash-Based Filtering section, I would add:




"Since encryption alters the meaning of encrypted fields, when the Hash-Based Filtering classification is based on the encrypted field(s) in the packet, it MUST be able to recognize that the field(s) are not available and not select those packets. Even
if they are ignored, the encrypted packets MUST be accounted in the Selector packetObserved Information Element [PSAMP-INFO], part of the Selection Sequence Statistics Report Interpretation."




- in the Security Considerations section, I would add next to first sentence (repeated here):

As IPFIX has been selected as the PSAMP export protocol and as
the PSAMP security requirements are not stricter than the IPFIX security
requirements, refer to the IPFIX export protocol [IPFIX-PROTO] for the security
considerations.

In the basic Packet Report, a PSAMP Device exports some number of contiguous bytes from the start of the packet, including the packet header (which includes link layer, network layer and other encapsulation headers) and some subsequent bytes of the
packet payload. The PSAMP Device SHOULD NOT export the full payload of conversations, as this would mean wiretapping [RFC 2804].



Feedback?

Regards, Benoit.







--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>