Subject: [BEHAVE] WGLC: draft-ietf-behave-stun-test-vectors-00

From: "Dan Wing" <[email-masked]>
Date: Mon, 4 Feb 2008 08:17:44 -0800

I am starting a two-week working group last call on
draft-ietf-behave-stun-test-vectors-00.txt, ending February 18:

http://tools.ietf.org/html/draft-ietf-behave-stun-test-vectors-00

Abstract:

   This document includes test vectors for the MESSAGE-INTEGRITY and
   FINGERPRINT attributes of the STUN protocol.

This document is being published as an Informational document.

-d

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 5 Feb 2008 15:09:56 +0200

Le Tuesday 05 February 2008 14:49:41 ext Philip Matthews, vous avez écrit :
> >    All included vectors are represented as a series of hexadecimal
> >    values in network byte order.  Each pair of hexadecimal digits
> >    represents one byte.
> >
> >    Messages follow the ICE Connectivity Checks use case of STUN, (see
> >    [I-D.ietf-mmusic-ice]).  They include both FINGERPRINT and MESSAGE-
> >    INTEGRITY attributes.
>
> You might want to say a bit more about the implications of the statement
> that these messages follow the ICE use case.

Well - the reason why this document uses ICE connectivity checks is simply 
that I wanted packets with all of the following attributes:
 - MESSAGE-INTEGRITY to check SHA-1 summing,
 - FINGERPRINT to check CRC32 summing,
 - XOR-MAPPED-ADDRESS to check XOR'ing,
 - any text field with "undefined" padding (namely USERNAME).

All four of these have actually proven to be buggy in some of the 
Work-In-Progress STUN stacks around here (including mine). Had STUN Binding 
Discovery *customarily* used all of these, I would have gone for it instead.

I don't mind adding more verbose descriptions (as long as it does not screw up 
the schematics layout :P). Then again, I didn't intend this document to be of 
much use to someone who does not even know the STUN message and attribute 
header formats - so the question is, should it or should it not?

-- 
Rémi Denis-Courmont