headers
Mark Smith | 1 Sep 2008 23:10

Re: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03)

Hi James,

On Wed, 27 Aug 2008 15:20:37 -0700
james woodyatt <jhw@...> wrote:

> On Aug 27, 2008, at 14:42, Mark Smith wrote:
> > Only permitting inbound authenticated tunneling protocols like  
> > IPsec, l2tp or pptp would easily defeat that.
> 
> IPsec is not necessarily authenticated.
> 

I had thought of that. Couldn't the statefulness/negotiated identity of
unauthenticated IPsec (and other stateful tunnelling protocols) at
least be the minimum threshold of what is allowed blindly?

Regards,
Mark.
Permalink | Reply | 0 comments |
headers
Mark Smith | 1 Sep 2008 23:37

Re: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03)

On Thu, 28 Aug 2008 09:48:25 +0200
Rémi Denis-Courmont <rdenis@...> wrote:

> 
> On Thu, 28 Aug 2008 07:12:00 +0930, Mark Smith
> 
> <ipng@...> wrote:
> 
> > In that case, I'd still strongly suggest limiting the IPv6 in IPv6
> 
> > tunnel support to authenticated protocols only. Bypassing the CPE
> 
> > security using a linux box (or anything else that supports end-user
> 
> > manually configured tunnels, on which the user has admin priviledges)
> 
> > will be as simple as something like this (syntax probably not right ,
> 
> > but that's because I've got a few minutes before I need to get ready for
> 
> > work):
> 
> 
> 
> This is silly. If the user wants to bypass the CPE, (s)he can do it anyway.
> 
> The point of a CPE is to provide security that the user _wants_ to have,
> 
> not force security upon the user.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
james woodyatt | 2 Sep 2008 22:53
Picon
Favicon

Re: tunnel protocols (draft-ietf-v6ops-cpe-simple-security-03)

On Sep 1, 2008, at 14:37, Mark Smith wrote:
> [...]
> Note the text doesn't specify a direction for these tunnelled  
> protocols:
>
> "Therefore, this document recommends the
>   DEFAULT operating mode for residential IPv6 simple security is to
>   permit all virtual private networking tunnel protocols to pass
>   through the stateful filtering function.  These include IPsec
>   transport and tunnel modes as well as other IP-in-IP protocols."
> [...]

This is the informative text in Section 2.2 of the Overview, whereas  
the Detailed Recommendations are split between sections 3.2.4 and  
3.2.5.  I think it would be more helpful if you were to address your  
concerns about sections 3.2.4 first, and 3.2.5 separately if necessary.

> [...]
> This would seem to me to allow unsolicited inbound tunnel  
> encapsulated traffic from any source, via any of the stateless over- 
> IPv6 tunnelling protocols or methods. I don't think that's very good  
> security at all, going slightly higher level than my earlier  
> example, here's the attack:
>
> (1) purchase a banner add on a popular webpage, with the  
> advertisement image coming from your server, and use that to record  
> valid and current global unicast IPv6 addresses.
>
> (2) attack those recorded addresses. Bypass all the v6 CPE security  
> measures specified in this draft by sending your malicious packets
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jari Arkko | 3 Sep 2008 01:02

FW: interim meeting on the topic of ipv4-ipv6 co-existence

FYI. Registration is now open, and hotel information is on the wiki:

> An interim meeting will be organized on October 1 - 2 in Montreal,
> Canada to continue discussions about the IPv4 and IPv6 co-existence,
> NAT-PT replacement, and new tunneling or translation solutions to
> address needs in this space. This is a meeting that affects work
> happening in a number of WGs (SOFTWIRE, V6OPS, BEHAVE, INTAREA).
>
> A wiki page containing more information about the meeting has been
> set up at http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
>
> We are currently working to provide hotel recommendations and other
> details.
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
Permalink | Reply | 0 comments |
headers
Rémi Després | 3 Sep 2008 14:44
Picon
Favicon

Interim meeting on ipv4-ipv6 co-existence - latest APBP document

The agenda in http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
has, for the APBP item of the agenda, draft-despres-v6ops-apbp as the
reference document.

In addition, slides 1-11 of the Dublin presentation
www.ietf.org/proceedings/08jul/slides/v6ops-8/v6ops-8, which are more up
to date, are useful.

Slides 12-20 can be ignored.
(The ad hoc protocol, despite its simplicity, is now proposed to be
replaced by an even simpler use of DHCP, the mapping between IPv4
address + port range and IPv6 addresses becoming static).

New material on this is planned to be brought to the meeting.

Note also that APBP (actually its revised version) fits in the "tunnel 
based solutions" item of the agenda.

Regards,

RD
Permalink | Reply | 0 comments |
headers
Dan Wing | 4 Sep 2008 00:39
Picon
Favicon

Re: translator friendly DNS Proxy


> -----Original Message-----
> From: Masahito.Endou <at> jp.yokogawa.com 
> [mailto:Masahito.Endou <at> jp.yokogawa.com] 
> Sent: Thursday, August 07, 2008 8:02 PM
> To: dwing <at> cisco.com; v6ops <at> ops.ietf.org
> Cc: behave <at> ietf.org; H.Miyata <at> jp.yokogawa.com
> Subject: RE: translator friendly DNS Proxy
> 
> Hi, Dan
> 
> > > Hi, all
> > >
> > > I submitted this document.
> > >
> > > In this document, I proposed DNS proxy that is separated
> > from NAT-PT.
> > > This document describes about relationship DNS proxy and 
> sNATPT[1].
> > > I think that this DNS proxy can collabolate with other translation
> > > technologies.
> > >
> > > I know that this working group isn't appropriate to discuss
> > such kind
> > > items, but I informed this document bacause many people that are
> > > interested in subscribed this mailing list.
> > > And, if there is more suitable working group to discuss it, please
> > > tell me that.
> >
> > The Behave working group would be best,
(Continue reading)

Permalink | Reply | 0 comments |
headers
H.Miyata | 4 Sep 2008 18:15

Re: translator friendly DNS Proxy

Oops,

Sorry, I would like to maintain it available.
Thanks for your comments.

Thanks,

.....miyata

________________________________________
差出人: Dan Wing [dwing <at> cisco.com]
送信日時: 2008年9月4日 7:39
宛先: Endou, Masahito (Masahito.Endou <at> jp.yokogawa.com); v6ops <at> ops.ietf.org
CC: behave <at> ietf.org; Miyata, Hiroshi (H.Miyata <at> jp.yokogawa.com)
件名: RE: translator friendly DNS Proxy

> -----Original Message-----
> From: Masahito.Endou <at> jp.yokogawa.com
> [mailto:Masahito.Endou <at> jp.yokogawa.com]
> Sent: Thursday, August 07, 2008 8:02 PM
> To: dwing <at> cisco.com; v6ops <at> ops.ietf.org
> Cc: behave <at> ietf.org; H.Miyata <at> jp.yokogawa.com
> Subject: RE: translator friendly DNS Proxy
>
> Hi, Dan
>
> > > Hi, all
> > >
> > > I submitted this document.
> > >
(Continue reading)

Permalink | Reply | 0 comments |
headers
james woodyatt | 6 Sep 2008 04:32
Picon
Favicon

implications of 6to4 for v6coex

everyone--

I've been reviewing RFC 3056, RFC 3068 and RFC 3964 with an eye toward  
composing draft guidelines for service providers deploying 6to4 relays  
for the exclusive use of their subscribers, i.e. *not* public 6to4  
relay services.  In the process, I've come to think that some  
additional recommendations from IETF are in order, specifically to  
deal with IPv6-IPv4 Coexistence (V6COEX) issues.  The intent of this  
message is to start a discussion on the topic.

I believe section 5.2 "Mixed scenario with relay to native IPv6" in  
RFC 3056 adequately describes the scenario of interest to the V6COEX  
effort.

In this scenario, the service provider has a mix of offerings,  
including 1) IPv4 service at globally routed addresses and 2) native  
or tunneled IPv6 service at globally routed addresses.  The V6COEX  
issue arises when a node in subscriber A, receiving IPv4-only service  
in its delegated 192.0.2.0/24 subnet, e.g. 192.0.2.1, elects to become  
a 6to4 site with its corresponding 6to4 prefix 2002:c000:201::/48 in  
order to communicate with native IPv6 nodes at subscriber B in the  
2001:db8:1::/48 prefix.

Here's an ASCII diagram to show how this scenario presents a V6COEX  
issue:

Subcriber                       Service Provider                Public
Networks                        Interior                        Internet

  Subscriber A
(Continue reading)

Permalink | Reply | 12 comments |
headers
Hiroshi MIYATA | 6 Sep 2008 09:32

Re: translator friendly DNS Proxy

Sorry, I forget to respond to another question.

I think there are not big differences between my+masahito's proposal  
and Bagnulo's.
There are some minor differences, like the method how to identify the  
synthetic
address. Even this, the concept is very close to snapt, since both  
proposed to
be recognize on around application layer.

Actually, the behavior is what I am insisting on my two proposals.
http://www.ietf.org/internet-drafts/draft-miyata-v6ops-trans-approach-01.txt
http://www.ietf.org/internet-drafts/draft-miyata-v6ops-snatpt-00.txt

And my presentation in 71st IETF. The presentation was done by Fred on  
behalf of me.

I and Masahito know that NAT-PT translation engine works with totd  
like dns proxy.
We have the implementations for more than 5 years. The behavior is  
very popular
among translator guys. It was introduced with TRT around 2000, as  
draft-endo-v6ops-dnsproxy-00.txt
mentioned. ;-)

I would respectfully ask Bagnulo, what is the biggest difference  
between us.

Dan, I agree with your modification request. Thanks a lot!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hiroshi MIYATA | 8 Sep 2008 12:37

Fwd: New Version Notification for draft-miyata-v6ops-snatpt-01

Hi all,

I updated my ID sNATPT, since previous one was expired in Aug.
I enriched the chapter of applicability for your easy understanding.
# I did not changed the file name, yet.

I appreciate your comments.

Kindly Regards,

....miyata

>
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission <at> ietf.org]
> Sent: Monday, September 08, 2008 6:58 PM
> To: Miyata, Hiroshi (H.Miyata <at> jp.yokogawa.com)
> Cc: Endou, Masahito (Masahito.Endou <at> jp.yokogawa.com)
> Subject: New Version Notification for draft-miyata-v6ops-snatpt-01
>
>
> A new version of I-D, draft-miyata-v6ops-snatpt-01.txt has been  
> successfuly submitted by Hiroshi Miyata and posted to the IETF  
> repository.
>
> Filename:        draft-miyata-v6ops-snatpt
> Revision:        01
> Title:           sNAT-PT: Simplified Network Address Translation -  
> Protocol Translation
> Creation_date:   2008-09-08
(Continue reading)

Permalink | Reply | 0 comments |

Gmane