Subject: RE: [Sipping] RE: draft-rosenberg-sipping-ice-01 & draft-camarill o-mmusic-alt-0 2.tx t

From: "Francois Audet" <[email-masked]>
Date: Sun, 26 Oct 2003 09:21:32 -0800

Good point. Thanks.

However, reading through STUN carefully, it seems to me that it only
allows for IPv4 addresses in the STUN messages themselves. For
example, the MAPPED-ADDRESS only allows for IPv4 addresses at this point.
Unless of course we extend it. (It currently only has a 0x01 Family
corresponding to IPv4).

So, unless I'm missing something, ICE today will not allow the use of STUN 
to verify connectivity to IPv6 addresses. We'd have
to assume that IPv6 addresses always work. We should probably explain
this in ICE, or expand STUN itself to allow for IPv6 addresses as well.
I'm wondering if STUN/ICE running only on IPv4 addresses wouldn't put IPv6
at a disadvantage over IPv4 addresses (they'd be less reliable).

When STUN was defined, it didn't make much sense to allow for IPv6
addresses,
because the purpose was to derive NATed addresses and discover the presence
of
NATs. However, ICE change the applicability of STUN to also be a mechanism
to
verify reachability. 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Saturday, October 25, 2003 03:34
> To: Audet, Francois [SC100:4K02:EXCH]
> Cc: 'Jonathan ROSENBERG ([email-masked])'; 'Gonzalo 
> Camarillo'; [email-masked]'
> Subject: Re: [Sipping] RE: draft-rosenberg-sipping-ice-01 & 
> draft-camarillo-mmusic-alt-0 2.tx t
> 
> 
> Francois,
> 
> such indicator is not necessary because all the alt lines contain 
> addresses of the same type as the main address for the m line (in a c 
> line that may be at the session level or at the m line level).
> 
> Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 26 Oct 2003 19:40:33 +0200

Francois,

if STUN is used only for NAT traversal, it may make sense to define only 
IPv4 addresses. Nevertheless, if we start using STUN to perform return 
routability tests to prevent DoS attacks (Jonathan has a draft about 
it), it will make sense to define IPv6 addresses as well.

To me, it makes sense to use the same mechanism for both things. This 
way, implementors are encouraged to implement it so that they can 
communicate with more people, and we kill two birds with the same stone. 
Otherwise, I do not know how much priority a specific mechanism for DoS 
prevention would get... people tend to ignore this type of thing until a 
big attack hits them.

Gonzalo

Francois Audet wrote:

> because the purpose was to derive NATed addresses and discover the 
> presence of
> NATs. However, ICE change the applicability of STUN to also be a 
> mechanism to
> verify reachability.
> 
> 
> 
> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Christian Stredicke" <[email-masked]>
Date: Sun, 26 Oct 2003 18:51:34 +0100

1) IPv4/IPv6

There will definitively be firewalls in IPv6. So we should include IPv6
right from the beginning.

Maybe it is possible to determine IPv4/IPv6 by the “look”. Address
“123.123.123.123” looks different than “1080::8:800:200C:417A”.

2) Expected Source Address

There is a trick to go though symmetrical NAT from everywhere: The
sender of the packets forges the source address with the expected source
address (writing on raw sockets). This makes the firewall think the
packet is coming from the expected source and let it pass through. It’s
a dirty trick but it works in many cases.

It would be nice if we have a description for the expected source
address.

CS

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag
von Francois Audet
Gesendet: Sonntag, 26. Oktober 2003 18:22
An: 'Gonzalo Camarillo'
Cc: 'Jonathan ROSENBERG ([email-masked])'; 'Gonzalo Camarillo';
[email-masked]'
Betreff: RE: [Sipping] RE: draft-rosenberg-sipping-ice-01 &
draft-camarillo-mmusic-alt-0 2.tx t

Good point. Thanks. 

However, reading through STUN carefully, it seems to me that it only 
allows for IPv4 addresses in the STUN messages themselves. For 
example, the MAPPED-ADDRESS only allows for IPv4 addresses at this
point. 
Unless of course we extend it. (It currently only has a 0x01 Family 
corresponding to IPv4). 

So, unless I'm missing something, ICE today will not allow the use of
STUN 
to verify connectivity to IPv6 addresses. We'd have 
to assume that IPv6 addresses always work. We should probably explain 
this in ICE, or expand STUN itself to allow for IPv6 addresses as well. 
I'm wondering if STUN/ICE running only on IPv4 addresses wouldn't put
IPv6 
at a disadvantage over IPv4 addresses (they'd be less reliable).