headers
Florent Parent | 1 Mar 2004 01:29
Favicon

Re: TSP (draft-blanchet-v6ops-tunnelbroker-tsp-00) comments


--On Monday, March 01, 2004 00:43:11 +0200 Pekka Savola
<pekkas@...> 
wrote:

> On Sun, 29 Feb 2004, Marc Blanchet wrote:

snip...

>> no. IP address is used to create the tunnel on both end. User
>> authentication is used to identify the user.
>
> Ok -- I think the problem is that the document does not describe other
> than which authentication mechanisms are used -- nothing at what
> key/account material or procedures are used prior to the mechanical
> authentication algorithm use.

understood. Will add in next rev.

>> > 4) SASL doesn't work with UDP, so my guess is that the whole UDP
>> > signalling must have been some kind of glitch in the spec.
>>
>> I will improve in next version. (it works, I'm using it every day...)
>
> Hmm.. unless I looked at it wrong, the SASL spec disagrees with you
> :-).

SASL spec supports "connection-based protocols". Using UDP requires you to 
establish and maintain a "connection" for the duration of the 
authentication exchange and tunnel setup.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Erik Nordmark | 1 Mar 2004 02:09
Picon

Re: Opportunistic Tunneling

> 
> > I think vendors can provide the infrastructure in their software that Bob
> talks > about (detecting existing IPv6 connectivity and prompting the user
> with "cool > application X needs IPv6 connectivity - should I set up such
> connectivity?").
> 
> would such a framework be a superset of the existing tranisition
> mechanisms, where the mechanism to be used would be selected based upon
> .... ? or would this actually be a new mechanism?
> 
> isn't there one software vendor that is already doing something similar
> when the user chooses to activate ipv6? is it something that needs to be
> standardized in the ietf?

I don't think this is something that needs to be standardized; this
is merely an issue of how the different software components (applications
and the protocol stack) on an implementation interact.

  Erik
Permalink | Reply | 0 comments |
headers
Pekka Savola | 1 Mar 2004 02:48
Picon

Re: TSP (draft-blanchet-v6ops-tunnelbroker-tsp-00) comments

On Mon, 1 Mar 2004, Florent Parent wrote:
> >> > 4) SASL doesn't work with UDP, so my guess is that the whole UDP
> >> > signalling must have been some kind of glitch in the spec.
> >>
> >> I will improve in next version. (it works, I'm using it every day...)
> >
> > Hmm.. unless I looked at it wrong, the SASL spec disagrees with you
> > :-).
> 
> SASL spec supports "connection-based protocols". Using UDP requires you to 
> establish and maintain a "connection" for the duration of the 
> authentication exchange and tunnel setup.
> 
> This will be explain in the next rev., along with the "reliable UDP" stuff.

Why exactly is UDP used here?  For signalling, TCP should be fine, and 
the actual tunnel doesn't use SASL in any case.

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Permalink | Reply | 0 comments |
headers
JORDI PALET MARTINEZ | 1 Mar 2004 03:18
Picon

Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt

Hi Pekka,

I see your point.

As more routers I try, more I find when isn't needed to configure anything: Is forwarded the same way as ICMP
or other protocols.

But of course, this depends on each manufacturer, and even it can change. I also find some where ICMP is
disabled by default ;-)

I think this is clearly a generic configuration issue in any "network box". Even it may depend in who install
the router. For example, some ISPs change the manufacturer's default configuration.

We will post an updated version most probably after this meeting, and will including a clarification on this.

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <pekkas@...>
To: "Marc Blanchet" <Marc.Blanchet@...>
Cc: <v6ops@...>; <jonne.soininen <at> nokia.com>; <mikael.lind@...>
Sent: Monday, March 01, 2004 6:30 AM
Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt

> Thanks for your feedback!
> 
> A few comments on your comments below.
> 
> Jordi, there is one comment on proto-41 forwardaring below which is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Huitema | 1 Mar 2004 08:12
Picon
Favicon

RE: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt

A couple of quick points regarding Teredo:

> >    In automatic tunnels like [Teredo] and [6to4], the bulk of the
> >    traffic between two nodes using the same technology is exchanged
on
> >    a direct path between the endpoints, using the IPv4 services to
> >    which the endpoints already subscribe. By contrast, the
configured
> >    tunnel servers carry all the traffic exchanged by the tunnel
client.
> >
> > <MB> Is "direct path always possible in all cases between Teredo
nodes?
> > </MB>
> 
> It isn't and this should be reflected here.

Actually, in the current design either all traffic will go on the direct
path, or no traffic will be exchanged at all.

> > ...
> >    by many applications, e.g., networked games or voice over IP. The
> >    experience shows that most recent "home routers" are designed to
> >    support these applications. In some edge cases, the automatic
> >    solutions will require explicit configuration of a port in the
home
> >    router, using the so-called "DMZ" functions.
> >
> > <MB>only works for one single node. Moreover, it should be noted
that
(Continue reading)

Permalink | Reply | 2 comments |
headers
Iljitsch van Beijnum | 1 Mar 2004 11:15
Favicon

Re: I-D ACTION:draft-ietf-v6ops-6to4-security-01.txt

On 10-feb-04, at 22:06, Internet-Drafts@... wrote:

> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security 
> -01.txt

Comments:

   "The 6to4 specification outlined quite a few security considerations,
    but it has been shown that in practice some of them have been
    difficult to get implemented due to their abstract nature."

How do you implement a consideration? And what exactly are you  
referring to? This is from RFC 3056:

   "In any case, any 6to4 traffic whose source or destination address
    embeds a V4ADDR which is not in the format of a global unicast
    address MUST be silently discarded by both encapsulators and
    decapsulators.  Specifically, this means that IPv4 addresses defined
    in [RFC 1918], broadcast, subnet broadcast, multicast and loopback
    addresses are unacceptable."

I don't find this particularly abstract, and apparently implementers  
didn't have much trouble with it either, this is from FreeBSD:

# netstat -rnf inet6
Destination       Gateway              Flags     Netif Expire
default           2002:c058:6301::     UGSc      stf0
2002::/24         ::1                  UGRSc      lo0 =>
2002::/16         2002:dfe0:e1e2::1    Uc        stf0
2002:7f00::/24    ::1                  UGRSc      lo0
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pekka Savola | 1 Mar 2004 16:14
Picon

Re: I-D ACTION:draft-ietf-v6ops-6to4-security-01.txt

Thanks for a lot of good comments.

I didn't know which of the comments were commentary in genreal, or 
where you were proposing a different text.  That is, it wasn't always 
clear what you were expecting the text to be.  But I'll try to address 
the issues the best way I can...

On Mon, 1 Mar 2004, Iljitsch van Beijnum wrote:
> > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security 
> > -01.txt
> 
> Comments:
> 
>    "The 6to4 specification outlined quite a few security considerations,
>     but it has been shown that in practice some of them have been
>     difficult to get implemented due to their abstract nature."
> 
> How do you implement a consideration? And what exactly are you  
> referring to? This is from RFC 3056:

The the text you quoted below, and then some more:

>    "In any case, any 6to4 traffic whose source or destination address
>     embeds a V4ADDR which is not in the format of a global unicast
>     address MUST be silently discarded by both encapsulators and
>     decapsulators.  Specifically, this means that IPv4 addresses defined
>     in [RFC 1918], broadcast, subnet broadcast, multicast and loopback
>     addresses are unacceptable."

And:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Savola | 1 Mar 2004 16:19
Picon

RE: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt

On Sun, 29 Feb 2004, Christian Huitema wrote:
> > >    a direct path between the endpoints, using the IPv4 services to
> > >    which the endpoints already subscribe. By contrast, the
> configured
> > >    tunnel servers carry all the traffic exchanged by the tunnel
> client.
> > >
> > > <MB> Is "direct path always possible in all cases between Teredo
> nodes?
> > > </MB>
> > 
> > It isn't and this should be reflected here.
> 
> Actually, in the current design either all traffic will go on the direct
> path, or no traffic will be exchanged at all.

It is true that this is an all-traffic/no-traffic issue (the latter 
caused by a flavor of NATs).  But aren't the latter ones, still, by 
definition Teredo nodes?

> > > ...
> > >    by many applications, e.g., networked games or voice over IP. The
> > >    experience shows that most recent "home routers" are designed to
> > >    support these applications. In some edge cases, the automatic
> > >    solutions will require explicit configuration of a port in the
> home
> > >    router, using the so-called "DMZ" functions.
> > >
> > > <MB>only works for one single node. Moreover, it should be noted
> that
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marc Blanchet | 1 Mar 2004 16:30
Favicon

RE: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt


-- Monday, March 01, 2004 17:19:50 +0200 Pekka Savola <pekkas@...>
wrote/a ecrit:

> On Sun, 29 Feb 2004, Christian Huitema wrote:
>> > > ...
>> > >    by many applications, e.g., networked games or voice over IP. The
>> > >    experience shows that most recent "home routers" are designed to
>> > >    support these applications. In some edge cases, the automatic
>> > >    solutions will require explicit configuration of a port in the
>> home
>> > >    router, using the so-called "DMZ" functions.
>> > > 
>> > > <MB>only works for one single node. Moreover, it should be noted
>> that
>> > this
>> > > explicit configuration is completly out of the _unmanaged_ goal.
>> > > 
>> > > Suggesting text:
>> > > using the so-called "DMZ" functions". These cases are obviously out
>> of
>> > > scope of the unmanaged network scenario and only work for a single
>> node
>> > > behind the NAT.
>> > > </MB>
>> > 
>> > Good point.
>> 
>> I agree that in the absence of automatic support through UPNP, DMZ
>> functions are indeed not your typical unmanaged service. But the point
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Huitema | 1 Mar 2004 18:04
Picon
Favicon

RE: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt

> >> I agree that in the absence of automatic support through UPNP, DMZ
> >> functions are indeed not your typical unmanaged service. But the
point
> >> is at least partially incorrect. First, it is possible in some
cases to
> >> use automatic procedures to "DMZ" a port (e.g., using the UPNP
> "internet
> >> gateway device" service). Second, the procedure that absolutely
work
> for
> >> more than one node -- just pick a different port for each node.
> >
> > I'm not sure that UPNP is a solution we can be referring to.
> 
> agree. unless I'm not aware, UPNP is not an IETF standard?

NAT is not an IETF standard either. On the other hand, the UPNP IGD spec
is publicly available and can certainly be referenced in an informative
section. 

> >> In any case, the work done in the MIDCOM working group shows that
the
> >> number of symmetric NAT in the market is rapidly decreasing. See
> >> draft-jennings-midcom-stun-results-00.txt
> >
> > Sigh -- replacing "secure" NAT boxes with "insecure" ones.
> > Now I'm done -- I said "secure NAT"! :-)
> 
> agree.
> - this argument of "most are not" does not go far to me. We are
(Continue reading)

Permalink | Reply | 1 comment |

Gmane