Talk:Resource attack: Difference between revisions
Jump to navigation
Jump to search
imported>Howard C. Berkowitz (New page: {{subpages}}) |
imported>Sandy Harris |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{subpages}} | {{subpages}} | ||
== SYNs and ACKs == | |||
The description here of which messages have which flags set is different from what I thought it was. Checking the CERT document linked, their description is different from both. [[User:Sandy Harris|Sandy Harris]] 15:16, 25 June 2010 (UTC) | |||
:OK, while the page looks OK to me, let me describe, from wetware memory of lots of protocol analyzer traces. There are nuances for connection collision that probably aren't relevant. | |||
:Originator sends SYN with proposed send sequence number and credit | |||
:Receiver sends SYN-ACK with proposed received sequence number if connection accepted; silent if rejecting connection | |||
:Originator confirms three-way handshake with SYN-ACK and updated bidirectional sequence numbers. | |||
:In a SYN-FLOOD, attacker repeats the first message but never the third. | |||
--[[User:Howard C. Berkowitz|Howard C. Berkowitz]] 15:34, 25 June 2010 (UTC) | |||
:: Page says sequence is SYN SYN SYN-ACK You say SYN SYN-ACK SYN-ACK and CERT give SYN SYN-ACK ACK. I'm almost certain CERT would be correct. [[User:Sandy Harris|Sandy Harris]] 15:57, 25 June 2010 (UTC) | |||
:::What does the RFC say? If we're going to these levels, the state machine is also going to be looking at the sequence numbers. We'll take the TCP RFC over CERT. I may have misspoken and it is closer to SYN SYN SYN-ACK, but with sequence number constraints on the second step.[[User:Howard C. Berkowitz|Howard C. Berkowitz]] 16:50, 25 June 2010 (UTC) | |||
::: Looking for something else, SYN/ACK T-shirt. [http://www.thinkgeek.com/tshirts-apparel/unisex/itdepartment/5b81/] [[User:Sandy Harris|Sandy Harris]] 14:08, 28 June 2010 (UTC) | |||
Latest revision as of 09:08, 28 June 2010
SYNs and ACKs
The description here of which messages have which flags set is different from what I thought it was. Checking the CERT document linked, their description is different from both. Sandy Harris 15:16, 25 June 2010 (UTC)
- OK, while the page looks OK to me, let me describe, from wetware memory of lots of protocol analyzer traces. There are nuances for connection collision that probably aren't relevant.
- Originator sends SYN with proposed send sequence number and credit
- Receiver sends SYN-ACK with proposed received sequence number if connection accepted; silent if rejecting connection
- Originator confirms three-way handshake with SYN-ACK and updated bidirectional sequence numbers.
- In a SYN-FLOOD, attacker repeats the first message but never the third.
--Howard C. Berkowitz 15:34, 25 June 2010 (UTC)
- Page says sequence is SYN SYN SYN-ACK You say SYN SYN-ACK SYN-ACK and CERT give SYN SYN-ACK ACK. I'm almost certain CERT would be correct. Sandy Harris 15:57, 25 June 2010 (UTC)
- What does the RFC say? If we're going to these levels, the state machine is also going to be looking at the sequence numbers. We'll take the TCP RFC over CERT. I may have misspoken and it is closer to SYN SYN SYN-ACK, but with sequence number constraints on the second step.Howard C. Berkowitz 16:50, 25 June 2010 (UTC)
- Looking for something else, SYN/ACK T-shirt. [1] Sandy Harris 14:08, 28 June 2010 (UTC)