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

2017-01-12 Thread Hu, Jun (Nokia - US)
I think this is similar case as NAT-T , where system need to update address:port if NAT mapping is changed ( described in last point of 2.23 of RFC7296 ); RFC 7296 says: "dynamic address update should only be done in response to a new packet; otherwise, an attacker can revert the

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

2017-01-12 Thread Tommy Pauly
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 draft-pauly-ipsecme-split-dns-02

2017-01-12 Thread Paul Wouters
On Thu, 12 Jan 2017, Tero Kivinen wrote: I might not want to trust the VPN gateway of our partner claiming to be authorative for mycompany.com, i.e., I will have policy limiting what is accepted from the gateway. Also when using opportunistic authentication we might want to have even strictier

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

2017-01-12 Thread Valery Smyslov
> > > 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

2017-01-12 Thread Tero Kivinen
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

2017-01-12 Thread Valery Smyslov
> > 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 draft-pauly-ipsecme-split-dns-02

2017-01-12 Thread Tero Kivinen
Valery Smyslov writes: > > > > This way if you have originally configured company1.com to the > > > > internal dns names, and then company decides to buy another company > > > > called company2.com, teh client can still request company1.com and > > > > server can return both company1.com and

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

2017-01-12 Thread Tero Kivinen
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 draft-pauly-ipsecme-split-dns-02

2017-01-12 Thread Valery Smyslov
> > > This way if you have originally configured company1.com to the > > > internal dns names, and then company decides to buy another company > > > called company2.com, teh client can still request company1.com and > > > server can return both company1.com and company2.com in its reply. > > >

Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02

2017-01-12 Thread Tero Kivinen
Valery Smyslov writes: > > This way if you have originally configured company1.com to the > > internal dns names, and then company decides to buy another company > > called company2.com, teh client can still request company1.com and > > server can return both company1.com and company2.com in its

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

2017-01-12 Thread Valery Smyslov
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

[IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01

2017-01-12 Thread Tero Kivinen
Timothy Carlin writes: > My comments: > > * Section 4 mentions that that 256-bit keys are raised to the SHOULD level.  > Should this read as these are now the MUST level as ENCR_AES_CBC and > ENCR_AES_GCM_16 are at the MUST level according to Table 1 (with the [1] > endnote)? Yes, I think this

Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02

2017-01-12 Thread Valery Smyslov
Hi Tero, > -- > >From section 3.2 > >If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non- >zero lengths, the CFG_REPLY MUST NOT assign any domains in its >INTERNAL_DNS_DOMAIN attributes that are not contained within the >requested domains. The initiator SHOULD