Subject: [BEHAVE] Comments on draft-ietf-behave-rfc3489bis-07

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Jul 2007 13:44:02 +0200

Hi,

I have reviewed the draft and have couple of comments. Mostly minor 
nits, but there are a few that I would like to have answers on. But 
otherwise I think the draft is quite easy to read.

1. Section 7.2.1: I wonder if there shouldn't be a recommended minimal 
RTO time. I think 100 ms is small enough for all implementations. 
Configuring anything smaller seems to me to be inviting a to big risk to 
miss any replies because the total time waited until failure is declared 
is well within the time it could take for a request to traverse some 
path if the client is misstaking what paths it actually is on.

2. Section 7.2.2: I think there is some unclarity in regards to which 
event one starts ones failure timer when using TCP. Please remember that 
if it is the SYN that are lost in the connectivity establishment process 
then there will be only a one retransmission every 3 seconds. Thus 
during the 7.9 seconds there will be only 2 retransmissions. If one 
counts from succesful connectivity establishment one needs some timeout 
also for the connectivity step. In general TCP will manage fewer 
retransmissions than UDP with a RTO of 100 ms.

3. Section 10.2.1.1: I think it is unclear how the server is going to 
know that longterm credentials shall be used. Is there an assumption 
here that any STUN server using long-term credentials will use them for 
all requests? If that is the case that should be mentioned.

4. Does STUN work with deploying servers with anycast addresses? If no, 
then maybe it needs to be documented?

5. Section 15: I think it might be worth to mention that an attacker can 
use a STUN server to bounce messages of them towards a target. There are 
no amplification, but it can be used by an attacker to disperse attacks 
streams so that they appear to come from many different sources to 
reduce. But it assumes that they can spoof the source address of the 
packet reaching the server. Especially for usages when there are no 
integrity checks the STUN server will have no identity of the attacker.

Nits

N1. Section 14.4: I think there are two sentences in this paragraph that 
are in contradiction:

"The text used as input to HMAC is the STUN message,
    including the header, up to and including the attribute preceding the
    MESSAGE-INTEGRITY attribute."

"Since the hash is computed over the entire STUN message, it includes
    the length field from the STUN message header."

As I see it the problem is the "entire" in the second sentence.

N2. Section 15.1.1:
    An attacker can try to modify STUN messages in transit, in order to
    cause a failure in STUN operation.  These attacks are prevented for
    both requests and responses through the message integrity mechanism,
    using either a short term or long term credential.

I think this paragraph is correct. You can always cause failure in STUN 
operation by modifying packets so the integrity fails or simple delete 
the packet. I think the paragraph needs to be reworded so that it 
doesn't ignore the fact. As I understand the goal of the paragraph is to 
say that with message integrity an attacker can't modify the STUN 
message to have STUN checks shutdown immeditely.

N3. Section 15.2.3: "This attack is similar to attack III." I don't 
think this sentence in inteded to reference the section it self is 
present in, maybe "II" is the right?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Jul 2007 07:41:10 -0400

> otherwise I think the draft is quite easy to read.

Great, thanks.

> path if the client is misstaking what paths it actually is on.

OK. I added that this is the minimum.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Jul 2007 08:01:29 -0400

sorry for the previous post, hit send by accident.

Great, thanks.

> retransmissions than UDP with a RTO of 100 ms.

I'd say its from the start of SYN. I agree this will cause fewer SYN 
retransmits.

> all requests? If that is the case that should be mentioned.

Yes. Basically its a function of the usage. A STUN server on the public 
network supporting ICE would use no authentication. A TURN server would 
always use long term. I noted this in the introductory text of section 10.

> then maybe it needs to be documented?

For UDP, when there is no authentication, STUN works with anycast. I 
mentioned this in setion 7.2.

> integrity checks the STUN server will have no identity of the attacker.

I mentioned this in section 15.1.2.

> As I see it the problem is the "entire" in the second sentence.

Right. Fixed.

> message to have STUN checks shutdown immeditely.

OK, I mentioned that, and clarified that this is only for on-path attackers.

> present in, maybe "II" is the right?

Yes, fixed.

Thanks,
Jonathan R.