(Apologies if this is a dupe. I sent it out yesterday, but it still hasn't shown up on the list yet, so I figured I better resend from a different account).
Here is another WESP extension that we are interested in. Packet Contents Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (PC) | Length | ContentType |Data (variable)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data(variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PacketContents (PC) option identifier (value TBD) Length: 2 octets ContentType: type of the packet contents description Data: depends on the ContentType The purpose of this option is to exchange information about the contents of the payload data to intermediaries (network infrastructure). This can be used both with full payload encryption or with just integrity. When the entire payload data is encrypted, some intermediaries, for instance packet filterers and deep content inspectors, lose the ability to perform their function. With this extension, the end host can append the PacketContents option to describe the contents of the packet for the benefit of intermediary devices. There are many possible uses for this. For instance, the endhost could have a classification scheme that maps HTTP to 1, LDAP to 2, SMB to this class of server to 3, SMB to another class of server to 4, etc. Hence there needn't be direct information disclosure of the encrypted data types to an attacker who didn't have access to the policy. Another possible use would be to expose the full URL for the request by duplicating it into the option. An example of a use for this with integrity only encapsulation is to flag things that are difficult to deduce by an intermediary. For instance, RPC commonly runs on dynamic ports. So we can flag the RPC packets with a specific tag. Clearly this puts trust in the end-system to apply the correct markings. But in a fully encrypted end-to-end environment, the intermediaries must trust the end systems somewhat anyway. And for integrity-only mode, these markings could be treated as hints to aid parsing. brian From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer Sent: Sunday, November 29, 2009 9:21 AM To: ipsec@ietf.org Subject: [IPsec] Proposed work item: WESP extensibility This draft proposes an extensibility framework for WESP, as well as several specific extensions. Proposed starting point: http://tools.ietf.org/id/draft-montenegro-ipsecme-wesp-extensions-00.txt. Please reply to the list: - If this proposal is accepted as a WG work item, are you committing to review multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? Please also reply to the list if: - You believe this is NOT a reasonable activity for the WG to spend time on. If this is the case, please explain your position. Do not explore the fine technical details (which will change anyway, once the WG gets hold of the draft); instead explain why this is uninteresting for the WG or for the industry at large. Also, please mark the title clearly (e.g. "DES40-export in IPsec - NO!").
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
