[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Idr] proposed additional text



In message <20040517144401.N28063@nexthop.com>, Jeffrey Haas writes:
> On Mon, May 17, 2004 at 12:52:05PM -0400, Curtis Villamizar wrote:
> > A replay attack involves sending information later on when it is no
> > longer valid.  Since the TCP sequence number is covered by the TCP
> > checksum, and therefore MD5 digest that replaces it, a replay attack
> > is not possible.  It also covers address and port so you can't read
> > from one connection and replay on another.
> 
> Presume you are in circumstances in which a replay attack is possible.
> Presume also that you can sniff the wire.
> Given the above, the circumstances under which an attack are valid are:
> 1. The key is still the same (or much less likely, a different key
>    results in the same MAC)
> 2. The source, dst, src port, dst port tuples are the same.
> 3. The segment which you are looking to replay is within the window.
> 
> Given all of the above, it is possible to replay the packet.
> If the packet is a SYN or RST, then you can obviously disrupt the session.
> You can gather these by simply sniffing the wire and simply replaying
> any that are within the acceptable TCP session and window.
> 
> If the packet is a data packet, the behavior will depend on the
> TCP implementation.  This may desynchronize the session at the
> least.
> 
> Note that I am not a TCP expert nor do I play one on TV.  However,
> I've heard some interesting stories about how different implementations
> fail to follow the spec and odd behaviors thus caused.
> 
> 
> -- 
> Jeff Haas 
> NextHop Technologies


Unless you can match the exact start and end of the packet after the
wrap occurs, all you have is a DoS attach that is good for one shot
every week or so.  And you have to be able to packet sniff to do it.

Real threat - very close to zero.  We have better things to worry
about.

If some implementation doesn't cease when the BGP flow gets out of
sync its very broken.

Curtis

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr