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

From: Benoit Claise <[email-masked]>
Date: Thu, 02 Mar 2006 16:41:04 +0100

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.

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 03 Mar 2006 01:24:05 +0100

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:

> 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
>
> requirements, refer to the IPFIX export protocol [IPFIX-PROTO] for the security
> considerations.
>
>
>
>
>
> "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."
>
>
>
> "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):
>
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 03 Mar 2006 01:27:18 +0100

Juergen,
> not export the full payload of a conversation?
I don't have the answer.
[PSAMP-FMWK] is not clearer:

      * Privacy: 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].  Full packet capture of arbitrary 
        packet streams is explicitly out of scope. 

Do you have a suggestion?

Regards, Benoit.
>> 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 
>> 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."
>>
>>
>>
>>
>> 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.
>>
>>
>>
>>

---

From: Andrew Johnson <[email-masked]>
Date: Fri, 03 Mar 2006 17:25:27 +0000

> Do you have a suggestion?

I think that the best we can do, and the spirit of the text, is
to simply not explain or make any special provisions for the
capture of full packets.  While our protocol may be used in such
a way, it will not be designed with this in mind.  We are creating
a tool, we cannot limit what the tool will be used for.

Andrew