Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

Hi Tommy, > >> Actually Valery did raise good point, that for IKE this might cause > >> issues. > >> > >> Now when I am thinking about this, I think that for IKE packets the > >> response to the IKE request should go to the same TCP session where > >> the request came in. This would be aligned

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

> On Jan 19, 2017, at 11:47 PM, Valery Smyslov wrote: > > HI Tero, > >> Actually Valery did raise good point, that for IKE this might cause >> issues. >> >> Now when I am thinking about this, I think that for IKE packets the >> response to the IKE request should go to the

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

HI Tero, > Actually Valery did raise good point, that for IKE this might cause > issues. > > Now when I am thinking about this, I think that for IKE packets the > response to the IKE request should go to the same TCP session where > the request came in. This would be aligned with the RFC7296

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

Hi Tero, > > If attacker intercepts TCP session carrying ESP packet with sequence > > 0x1000 and manages to get the packet and drop the TCP session before > > responder gets it, then it can create a new TCP session > > sending this packet. The responder will switch to the attacker's > > TCP

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

Tommy Pauly writes: > This MUST should probably be downgraded to a SHOULD, and add > explanation about the reuse case. The point of this text was to make > sure that initiators don’t needlessly leave TCP connections open to > responders, and take up resources on the responder. A better text >

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

Valery Smyslov writes: > > > > Initiator then recreates tcp session with responder and sends some ESP > > > > traffic with sequence numbers of 0x1001-0x1005. Attacker kills that > > > > TCP connection, creates completely new TCP session and replays the old > > > > ESP message with sequence number

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

ginal Message- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Valery Smyslov > Sent: Thursday, January 12, 2017 7:26 AM > To: 'Tero Kivinen' <kivi...@iki.fi> > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04 > > &g

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

Hi Tero, Thanks for the comments! Responses inline. Best, Tommy > On Jan 11, 2017, at 7:04 AM, Tero Kivinen wrote: > > This draft should be quite ready for the WGLC, so I will start that > shortly, but here are comments from my chair review of the draft. > > Consider these

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

> > > Initiator then recreates tcp session with responder and sends some ESP > > > traffic with sequence numbers of 0x1001-0x1005. Attacker kills that > > > TCP connection, creates completely new TCP session and replays the old > > > ESP message with sequence number of 0x1000 (which was not seen

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

Valery Smyslov writes: > > Initiator then recreates tcp session with responder and sends some ESP > > traffic with sequence numbers of 0x1001-0x1005. Attacker kills that > > TCP connection, creates completely new TCP session and replays the old > > ESP message with sequence number of 0x1000 (which

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

> > Isn't it easier to add a requirement that the received message must > > not be a replay? For example: > > > > It should choose the TCP > > connection on which it last received a valid and decryptable IKE or > > ESP message that is not recognized as a

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

Valery Smyslov writes: > > This should be happening anyways, as there will not be reordering happening > > inside the TCP connection, so this will not cause issues for normal > > cases. > > > > Same for the IKE SA, i.e. the message-id must be larger than anything > > seen before, not just

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

Hi once more, >The streams of data sent over any TCP connection used for this >protocol MUST begin with the stream prefix value followed by a >complete message, which is either an encapsulated IKE or ESP message. > ... > > I think this should be rephrased in a way that when initiator