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 addresses with old replayed packets. Because of this,
dynamic updates can only be done safely if replay protection is
enabled."
I think we could use same requirement (pass anti-replay) here since this is
same issue and tcp encap is not make thing worse;
> -----Original Message-----
> From: IPsec [mailto:[email protected]] On Behalf Of Valery Smyslov
> Sent: Thursday, January 12, 2017 7:26 AM
> To: 'Tero Kivinen' <[email protected]>
> Cc: [email protected]
> Subject: 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 by the server before). Responder will accept this as
> > > > valid non replayed ESP packet, and will move all traffic to this new TCP
> connection.
> > >
> > > What then? What benefits attacker gains and how it will exploit the
> > > fact it hijacks TCP connection? The responder will eventually
> > > recreate new TCP connection and everything will continue to work.
> >
> > As I said this is not serious, but it is vulnerability, which is easy
> > to fix.
>
> I don't think your fix really helps in this scenario.
>
> 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 session even with your
> proposal (until the initiator creates new TCP session and sends some ESP
> packets with higher SN).
>
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
