Hi, IMO We need to add the following enhancements to IPsec if we want to include handling of Dummy packets and TCP arbitrary padding
Dummy packets ============= 1). We need to add bits in odp_ipsec_warn_t to indicate the reception of dummy packets so that when an IPsec implementation receives an ESP packet with NH=59 he can send warning bits to the application. 2). If the application wants to send dummy packet he can set a bit and length of the packet in ipsec_out_param_t to initiate the implementation to send dummy packet. TFC arbitrary padding support ======================= 1) Inbound direction -- implementation will send the entire packet after decryption including TFC padding and application can retrieve the original packet from the length in the IP header. 3) Outbound direction -- application can generate and append TFC padding bytes to the original IP packet prior to sending to the IPsec processing. The application can indicate whether TFC padding is done on the packet and the length of the padding in odp_ipsec_out_param_t structure to indicate the same to the implementation. We may need to update IPSec capability structure according to supporting the above features. Regards, Bala Regards, Bala On 28 November 2017 at 22:43, Bill Fischofer <bill.fischo...@linaro.org> wrote: > On Tue, Nov 28, 2017 at 9:28 AM, Dmitry Eremin-Solenikov < > dmitry.ereminsoleni...@linaro.org> wrote: > >> Hello, >> >> On 20/11/17 18:23, Bill Fischofer wrote: >> > Traffic Flow Confidentiality (TFC) is a feature of SAs according to RFC >> > 4303 that must be negotiated on a per-SA basis before it is used. So >> > This would need to be hooked into higher-level protocols. >> > >> > From an ODP perspective, it would be an additional set of parameters on >> > the odp_ipsec_sa_create() API. Not clear this is something we should >> > worry about for Tiger Moth, but something to consider as an addition in >> > the future. >> >> In fact I think that control can go to application level. I was thinking >> about allowing application to specify if outgoing packet is dummy or >> not. In fact I'm going to propose the possibility to specify if outgoing >> packet is IPv4, IPv6 or dummy. >> > > Whether the outbound packets are IPv4 or IPv6 is controlled by the tunnel > mode configuration. For transport mode the input packet already has the > L3/L4 headers it needs. > > TFC enablement should be another odp_ipsec_sa_param_t option. Dummy packets > for output can be another odp_ipsec_out_opt_t bit setting. For RX, I think > we'd want to report dummy packet receipt as another odp_ipsec_warn_t bit. > I'm very reluctant to have ODP discard anything as that means that the > application can never see it and we'd have to maintain stats for these > discards anyway. Applications using IPsec should understand these packets > since they have to negotiate them anyway and should take whatever action > they wish with them. ODP should not limit application freedom of action in > this regard by making these decisions itself. > > >> >> > >> > On Mon, Nov 20, 2017 at 8:37 AM, Dmitry Eremin-Solenikov >> > <dmitry.ereminsoleni...@linaro.org >> > <mailto:dmitry.ereminsoleni...@linaro.org>> wrote: >> > >> > Hello, >> > >> > I was thinking about another minor part of IPsec RFCs: dummy packets >> > used to mask traffic statistics. IPsec implementation is required to >> > drop ESP packets with NH = 59 (no next header) on receiver side and >> is >> > expected to be able to generate these packets on transmitter side. >> > Currently we do not provide a way to inject these packets in any way. >> > >> > Possible solutions: >> > >> > TX side: >> > - Add API call to transmit single packet. >> > >> > - Extend transmit parameters to specify next header (IPv4, IPv6 or >> > NoNH) for each packet to be transmitted (per-packet or per-odp call). >> > >> > - ??? >> > >> > RX side: >> > - Silently drop NoNH packets >> > >> > - Report NoNH packets to app via error or status event mechanism. >> > >> > - ??? >> > >> > -- >> > With best wishes >> > Dmitry >> > >> > >> >> >> -- >> With best wishes >> Dmitry >>
