Subject: [Ietf-behave] comments on behave-tcp

From: Mark Allman <[email-masked]>
Date: Fri, 5 May 2006 09:20:33 -0700 (PDT)

Folks-

I am one of the TCPM co-chairs and Lars asked us to get a couple reviews
for the behave-tcp i-d.  A couple folks volunteered and I expect their
reviews will arrive soon.  Below are my quick comments on the document.
Basically, it looks fine to me.

I found some of this a little hard to grok because of the dependence on
[1].  A few more words around a bunch of the references might be useful
to help give someone the context.  (I am not advocating repeating all of
[1], but a little more help would be helpful.)

Swapping sections 4.2 and 4.3 would make things more natural to me.

I didn't follow the bit about "masquerad[ing] as the NAT'ed endpoint" in
section 8.  What is this?  I don't see how this is really practical
unless the attacker is in the path.  And, if that is the case then it
seems like the NAT isn't going to be able to foil the attack anyway.
Or, am I missing something here?

For the last paragraph in section 8 I think it'd be useful to cite Joe
Touch's antispoof document: draft-ietf-tcpm-tcp-antispoof-03.txt

FWIW.

allman

Attachment:
pgp00099.pgp

---

From: Saikat Guha <[email-masked]>
Date: Sun, 7 May 2006 18:19:07 -0700 (PDT)

Hi Mark,

Thanks for taking the time to review the document. Comments inline.

> [1].  A few more words around a bunch of the references might be useful

Ok.

> Swapping sections 4.2 and 4.3 would make things more natural to me.

My intention was to talk about internally initiated connections first
since it is the common mode of operation of a NAT, and an internal
connection needs to be established first before external connections can
be initiated.

Can you help me understand a bit more why 4.3 before 4.2 would make
things more natural for a reader.

> unless the attacker is in the path.

I suppose it is less important now since most stacks pick random initial
sequence numbers. If the sequence number were easily guessable by an
off-path attacker, then the attacker could spoof the entire TCP stream.

> Touch's antispoof document: draft-ietf-tcpm-tcp-antispoof-03.txt

Ok.

Thanks!
-- 
Saikat
Attachment:
signature.asc

---

From: Mark Allman <[email-masked]>
Date: Sun, 7 May 2006 19:40:17 -0700 (PDT)

> things more natural for a reader.

Ignore my comment.  It was the drugs.  You're clearly right.

> > I didn't follow the bit about "masquerad[ing] as the NAT'ed
> > endpoint" in section 8.  What is this?  I don't see how this is
> > really practical unless the attacker is in the path.
> 
> I suppose it is less important now since most stacks pick random
> initial sequence numbers. If the sequence number were easily guessable
> by an off-path attacker, then the attacker could spoof the entire TCP
> stream.

I still don't really understand what you're talking about.  How about a
quick example of this masquerading that you're worried about?

allman

Attachment:
pgp00102.pgp

---

From: Saikat Guha <[email-masked]>
Date: Tue, 9 May 2006 18:40:03 -0700 (PDT)

> > > really practical unless the attacker is in the path.

The concern was that an off-path attacker can spoof an entire TCP
session (if the initial sequence number can be guessed).

                     X
                     |
A ----- N -----------+------- B

1. X sends SYN to B. Spoof's source address as N.
2. X predicts B's initial sequence number. Say 0.
3. B sends SYNACK to N. N drops it silently.
4. X sends ACK packet with A's spoofed source ack'ing B's guessed   
   sequence #. Packet may contain data.
5. B acks data to N. N drops packets.
6. X sends more data and so on

X can blindly spoof A. 

If N were to send some response to packets 3 or 5, like a RST for
example ... then A/N's identity could not have been impersonated.

To that effect, the idea is to allow the NAT to respond to any packet
other than the initial incoming SYN with a RST if the vendor so decides.

The RST on SYN doesn't buy any extra security since this issue arises
only when the SYN was sent by the attacker (and therefor didn't cross
the NAT). In any event, there are subsequent packets to refute if such
an attack is underway -- like the ACK or SYNACK.

-- 
Saikat
Attachment:
signature.asc

---

From: Mark Allman <[email-masked]>
Date: Tue, 9 May 2006 19:18:38 -0700 (PDT)

> 6. X sends more data and so on

I see where you're going now.  This seems like a really theoretical
attack to me.  First we know that ISNs ought to be random - which
essentially defeats this attack.  But, even if you hit the ISN lottery X
has to guess what was sent and if B needs more than simple ACKs (e.g.,
an application reply) to continue then you're hosed.  

Basically, for this document I don't even see a point in raising this
issue.  Because it's not an issue.  But, if you are going to raise it,
I'd recommend more than one passing remark about it.  You should fully
explain this "threat".

allman

Attachment:
pgp00104.pgp

---

From: Saikat Guha <[email-masked]>
Date: Wed, 10 May 2006 09:05:37 -0700 (PDT)

On Tue, 2006-05-09 at 22:17 -0400, Mark Allman wrote:
> I'd recommend more than one passing remark about it. 

Fair enough. Actually, come to think on the flip side sending the RST
can actually (slightly) worsen a DoS attack. 

If no RST is sent, the attacker spoofs many SYN packets, the target
responds with SYNACKs (potentially using TCP SYN-cookies) and network
bandwidth is used.

If an RST is sent by N, then that amplifies the DoS by 50% (3 packets
instead of 2).

As for the TCP blindly spoofing a connection, I suspect you are right
that it is theoretical today. I do recall hearing about someone actually
pulling it off a long long time ago (the Mitnik case was it perhaps?)
but there the victim stack was hardcoded to use ISN=0 I think.

In any event, I agree that the issues on both sides should be made more
clear.

cheers,
-- 
Saikat
Attachment:
signature.asc