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
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
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
> > > 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
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
> > 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
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
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
> > > 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.
> > >
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
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
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
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
13 matches
Mail list logo