headers
Oscar Novo | 2 May 2008 12:05
Picon
Favicon

Re: Comments on draft-ietf-behave-turn-ipv6-04

Simon,

Thanks for your comments. We'll include them in the next version. 
Regarding your comment 4.2, the draft already defined a 420 (unknown
attribute) for a wrong family.

Cheers,

Oscar

-----Original Message-----
From: Simon Perreault [mailto:simon.perreault <at> viagenie.ca] 
Sent: 29. huhtikuuta 2008 16:12
To: Gonzalo Camarillo; Oscar Novo
Cc: behave <at> ietf.org
Subject: Comments on draft-ietf-behave-turn-ipv6-04

Hello,

I had a first reading of draft-ietf-behave-turn-ipv6-04. Here are a few
comments.

1. Last paragraph of section 4.1:

   The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate
   Requests.

This is in contradiction with section 4.2 which describes the usage of
REQUESTED-ADDRESS-TYPE in the Refresh request.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Oscar Novo | 2 May 2008 13:32
Picon
Favicon

Nueva versión de turn: draft-ietf-behave-turn-ipv6-05

Buenas,

Aquí te envio la nueva versión del draft con los comentarios del tio (abajo).

Oscar

-----Original Message-----
From: Simon Perreault [mailto:simon.perreault <at> viagenie.ca] 
Sent: 29. huhtikuuta 2008 16:12
To: Gonzalo Camarillo; Oscar Novo
Cc: behave <at> ietf.org
Subject: Comments on draft-ietf-behave-turn-ipv6-04

Hello,

I had a first reading of draft-ietf-behave-turn-ipv6-04. Here are a few comments.

1. Last paragraph of section 4.1:

   The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate
   Requests.

This is in contradiction with section 4.2 which describes the usage of REQUESTED-ADDRESS-TYPE in the
Refresh request.

Also, s/REQUEST/REQUESTED/.

2. In section 4.2, there is confusing talk about bindings. Please s/binding/allocation/ because you do
not want to confuse the reader with STUN bindings when you're really talking about TURN allocations.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rémi Denis-Courmont | 2 May 2008 14:04
Picon

Re: IPv4/IPv6 relayed address allocation

Le Thursday 24 April 2008 23:17:13 ext Philip Matthews, vous avez écrit :
> > IMHO, I think TURN-07 is wrong and TURN-IPv6 is right.
> >
> > The relay cannot know if there was a protocol translator in the
> > middle, so that would be the only way to obtain sane defaults.
> >
> > So either the client must always explicitly specify the address
> > family, or the default should be independent of the relay-reflexive
> > address of the client.
>
> Sorry to be slow in replying here.
>
> I would really prefer to stick with the current turn-07 proposal and
> fix turn-ipv6 to match.
>
> If we went with the turn0-ipv6 proposal, then the base TURN
> specification would have to specify how to relay between IPv6 and
> IPv4.

In either case, IPv6 support is currently somewhat broken in TURN-07. 
Especially, the handling IPv6 flow information field is left unspecified, 
which is certainly wrong.

From a more general perspective, having the application-layer semantics depend 
on the IP protocol version of the client looks like very bad engineering to 
me. Imagine DNS servers would return different results depending if you query 
them over v4 or v6!?!

Looking at TURN-07:
(Continue reading)

Permalink | Reply | 83 comments |
headers
Rémi Denis-Courmont | 2 May 2008 14:06
Picon

Re: Consensus call on Adding "Client" attribute to STUN


	Dan,

I think I'll wait for the conclusion of this before I update the test vectors. 
I can see it coming that people will ask for a CLIENT attribute there.

Is that OK?

Le Thursday 24 April 2008 20:31:25 ext Magnus Westerlund, vous avez écrit :
> This is a one week+ consensus call (until the 5th of May) if the WG
> thinks that STUN (draft-ietf-behave-rfc3489bis) shall be extended with
> an additional attribute "Client" before publication.
>
> With the general description along the lines of:
>
>     X.Y CLIENT
>
>     The client attribute contains a textual description of the software
>     being used by the client, including manufacturer and version number.
>     The attribute has no impact on operation of the protocol, and serves
>     only as a tool for diagnostic and debugging purposes.  The value of
>     CLIENT is variable length.  It MUST be a UTF-8 [RFC3629] encoded
>     sequence of less than 128 characters (which can be as long as 763
>     bytes).
>
> And some Security Considerations on the risk for targeted attacks
> against clients with this information. Plus other text needed to bring
> it in consistently
>
> The text is open for wordsmithing by the editors of the STUN spec.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Simon Perreault | 2 May 2008 14:22
Picon
Favicon

Re: Comments on draft-ietf-behave-turn-ipv6-04

On Friday 02 May 2008 06:05:14 Oscar Novo wrote:
> Regarding your comment 4.2, the draft already defined a 420 (unknown
> attribute) for a wrong family.

That's not what I was talking about. By "wrong family" I meant "of a different 
(but known) family than the one previously allocated." This only makes sense 
in the context of refreshing an existing allocation.

> 3. In section 4.2:
>
>    If the Allocate Response contains the same transport address as
>    previously obtained, the binding has been refreshed.
>
> There's an "else" missing. I suggest that server refresh the allocation
> if the REQUESTED-ADDRESS-TYPE attribute is missing or of the same type
> as previously allocated. If it is present but of the wrong family, reply
> with a 400 Bad Request.
Permalink | Reply | 1 comment |
headers
Oscar Novo | 2 May 2008 15:13
Picon
Favicon

Re: Comments on draft-ietf-behave-turn-ipv6-04

OK, now I understand your point. We could add this in the next version
as well.

Thanks,

Oscar 

-----Original Message-----
From: Simon Perreault [mailto:simon.perreault <at> viagenie.ca] 
Sent: 2. toukokuuta 2008 15:23
To: Oscar Novo
Cc: Gonzalo Camarillo; behave <at> ietf.org
Subject: Re: Comments on draft-ietf-behave-turn-ipv6-04

On Friday 02 May 2008 06:05:14 Oscar Novo wrote:
> Regarding your comment 4.2, the draft already defined a 420 (unknown
> attribute) for a wrong family.

That's not what I was talking about. By "wrong family" I meant "of a
different (but known) family than the one previously allocated." This
only makes sense in the context of refreshing an existing allocation.

> 3. In section 4.2:
>
>    If the Allocate Response contains the same transport address as
>    previously obtained, the binding has been refreshed.
>
> There's an "else" missing. I suggest that server refresh the 
> allocation if the REQUESTED-ADDRESS-TYPE attribute is missing or of 
> the same type as previously allocated. If it is present but of the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 2 May 2008 17:52
Picon
Favicon

Re: Consensus call on Adding "Client" attribute to STUN

As chair: fine by me.  I was hoping more people would comment for/against
Magnus's consensus call. 

As an individual and co-author of rfc3489bis:  I support adding the new CLIENT
attribute.

-d

> -----Original Message-----
> From: Rémi Denis-Courmont [mailto:remi.denis-courmont <at> nokia.com] 
> Sent: Friday, May 02, 2008 5:06 AM
> To: Dan Wing
> Cc: behave <at> ietf.org
> Subject: Re: [BEHAVE] Consensus call on Adding "Client" 
> attribute to STUN
> 
> 
> 	Dan,
> 
> I think I'll wait for the conclusion of this before I update 
> the test vectors. 
> I can see it coming that people will ask for a CLIENT attribute there.
> 
> Is that OK?
> 
> Le Thursday 24 April 2008 20:31:25 ext Magnus Westerlund, 
> vous avez écrit :
> > This is a one week+ consensus call (until the 5th of May) if the WG
> > thinks that STUN (draft-ietf-behave-rfc3489bis) shall be 
> extended with
(Continue reading)

Permalink | Reply | 1 comment |
headers
Philip Matthews | 2 May 2008 21:16
Picon

Re: IPv4/IPv6 relayed address allocation


On Fri, 2-May-08, at 08:04 , Rémi Denis-Courmont wrote:
> Le Thursday 24 April 2008 23:17:13 ext Philip Matthews, vous avez  
> écrit :
>>> IMHO, I think TURN-07 is wrong and TURN-IPv6 is right.
>>>
>>> The relay cannot know if there was a protocol translator in the
>>> middle, so that would be the only way to obtain sane defaults.
>>>
>>> So either the client must always explicitly specify the address
>>> family, or the default should be independent of the relay-reflexive
>>> address of the client.
>>
>> Sorry to be slow in replying here.
>>
>> I would really prefer to stick with the current turn-07 proposal and
>> fix turn-ipv6 to match.
>>
>> If we went with the turn0-ipv6 proposal, then the base TURN
>> specification would have to specify how to relay between IPv6 and
>> IPv4.
>
> In either case, IPv6 support is currently somewhat broken in TURN-07.
> Especially, the handling IPv6 flow information field is left  
> unspecified,
> which is certainly wrong.

This is being fixed.
TURN-08 will say that a server should copy the flow label, and if this  
cannot be done, then treat the packets to/from each peer as a separate
(Continue reading)

Permalink | Reply | 82 comments |
headers
Simon Perreault | 2 May 2008 21:35
Picon
Favicon

Re: IPv4/IPv6 relayed address allocation

On Friday 02 May 2008 15:16:02 Philip Matthews wrote:
> What if the base spec included the REQUESTED-ADDRESS-TYPE attribute
> with the restriction that the address type given in the REQUESTED-
> ADDRESS-TYPE attribute MUST match the address type in the 5-tuple or
> the Allocate request is rejected ?
> TURN-IPv6 would then lift this restriction.
>
> Would this make things better?

Hehehe, that would be the shortest RFC ever.

===================

Abstract

This memo lifts a restriction concerning mixed address types in RFCXXXX.

1. Lifting a Restriction

The restriction to the effect that the address family contained in the 
REQUESTED-ADDRESS-TYPE attribute must match that of the server address is 
hereby lifted.

2. IANA Considerations

None.

3. Security Considerations

None.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mary Barnes | 3 May 2008 00:44
Favicon

Re: WG Review: draft-ietf-sipping-nat-scenarios-07

Hi folks,

This is to announce a Working Group Last Call on the following document
to be published a Best Current Practice (BCP):
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-08.
txt

The review period will end on 23 May 2008 (3 weeks time). 

Note that I have cross-posted to the BEHAVE and MMUSIC WGs, but ask that
you please send your comments only to the SIPPING WG and author(s). 

The following reviewers have already volunteered:  Vijay Gurbani,
Spencer Dawkins, Francois Audet, and Dan Wing  (thanks guys!)

However, we do encourage others to review and make any final comments on
the document at this time.  

Thanks,
Mary
SIPPING WG co-chair

As a reminder, the SIPPING WG review guidelines are available at:
https://softarmor.com/sipping/process/wg-review/sipping-review-guideline
s.html
Permalink | Reply | 14 comments |

Gmane