Re: [arch-d] ipv4 and ipv6 Coexistence.

Guntur Wiseno Putra <gsenopu@gmail.com> Thu, 27 February 2020 05:19 UTC

Return-Path: <gsenopu@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A51D3A0CB1 for <architecture-discuss@ietfa.amsl.com>; Wed, 26 Feb 2020 21:19:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q2ieJNWekcf for <architecture-discuss@ietfa.amsl.com>; Wed, 26 Feb 2020 21:19:15 -0800 (PST)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01F83A11C0 for <architecture-discuss@ietf.org>; Wed, 26 Feb 2020 21:19:14 -0800 (PST)
Received: by mail-ot1-x32d.google.com with SMTP id r16so1814873otd.2 for <architecture-discuss@ietf.org>; Wed, 26 Feb 2020 21:19:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RPZwtFwYs4cmmI+XoiEo+1FM2L5he++RcUM1X9ETgfY=; b=eB1XzibiTroLPlo7jALFA4S3mn2QsLE+mHESK1+Yr6PJNcyIsLRCIsg+aC6C3QPdbs 7U8QCV4XZEl0A9Om7v0SQONZzY2+vKE84rEWUBCrBBd9Wnj5cbcquwEY+JsBZ25RoeEO +IxvJ86znpdgB0agqXU3y90Y/bKygTtEA4PiEuHOLHrH/P4JWzza4GJBO5GWPV4NIcCp 7N6bz9LFPf0p5C3LXcsE/9E/BaNQnE5JmeipETMOC3VyCnsPxdOCO/xnCEaGlZpBxC1O av8MyvVRLtFpRaJbqIgyQGLI6snI5htoMqRwj5yrG83QagMe+EbF+hqAqsqdur714Tsu TsuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RPZwtFwYs4cmmI+XoiEo+1FM2L5he++RcUM1X9ETgfY=; b=R/+yf3zuelnO7ZafUiUcATuZmanyvfjPPvbM/uH3aRSC1xibnSW1YqG58F52rap5sH Ivmiqz+FREcC11t+cpW26HmeGUIiNoTGzUZeWodu7qagO/nchf7RcfrU3+nppNNmV1ba f2Go+aDLKjuzegmJ5wmiMflcypk4xdSmikCYujeOd6lrSPKVD5QwfVteWZ4gqGc0UVpS TTFxjagxpZuRsv1x/t0Dg0Nkxzwsu/H6ytCbzb535AbNH+Bfakf3D26L53u3683q6KoM pab+QbUth0J/huAMPq5KDDHYC1b7KShyPwCO6iucNHl2Q6AhjFapP9+Ld50MNg/qAJ7F l7Uw==
X-Gm-Message-State: APjAAAWklOQMPjIIpLA5MBfNPJU6QV8qoEmEVDBklg3DQvNgpMuRGO1k zbQ77LCnZ6WnB4NcBH5Qpeypc9LaP2Pm9EeQ2hM=
X-Google-Smtp-Source: APXvYqx7hrEF7ZEd7po0TuRfaytaZCSdMTUsXm0PBv9OgLlqmABrXS3YtujLSOrnvo/fa4yAj6F+sRDzNGACc3AkjbA=
X-Received: by 2002:a05:6830:1e76:: with SMTP id m22mr1974290otr.295.1582780752969; Wed, 26 Feb 2020 21:19:12 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Wed, 26 Feb 2020 21:19:12 -0800 (PST)
In-Reply-To: <20200226210048.GL39574@faui48f.informatik.uni-erlangen.de>
References: <EDAE6375-EE0B-4864-9834-C1FBC209D581@sobco.com> <PR3P194MB08431E138262F2A43C1D0621AE100@PR3P194MB0843.EURP194.PROD.OUTLOOK.COM> <8ADEA0E1-291A-4400-9925-F65A26116372@consulintel.es> <PR3P194MB0843939F3B38426960A66E70AE130@PR3P194MB0843.EURP194.PROD.OUTLOOK.COM> <D8063303-7DDA-41F8-A63A-C0244E3E9E25@isc.org> <20200224222715.GA49892@faui48f.informatik.uni-erlangen.de> <28C4725E-E4C5-4937-835F-C6DEA9B710CF@gmail.com> <20200225202403.GG39574@faui48f.informatik.uni-erlangen.de> <0755B3F6-D90F-4F85-8D33-7C9C118FB475@gmail.com> <75ecdea9-ab6f-f20b-bb1f-8740cbe9c159@cs.tcd.ie> <20200226210048.GL39574@faui48f.informatik.uni-erlangen.de>
From: Guntur Wiseno Putra <gsenopu@gmail.com>
Date: Thu, 27 Feb 2020 12:19:12 +0700
Message-ID: <CAKi_AEu29F+SuhjmRdmaq_NSGXPaSOrOFrFRmRH_UACf=Lnwow@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000089c1aa059f87dc39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/8O9WMFMHhAKUZZLXCanh_54ZNQc>
Subject: Re: [arch-d] ipv4 and ipv6 Coexistence.
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2020 05:19:19 -0000

Dear architecture-discuss,

I am struggling to read on what Pekka Nikkander made about "IPv4 & IPv6" in
"Reflection on Architecture" (2005) where he mentioned about the time of
architecture-discuss' beginning:


(P. Nikander:)

"...Looking at the network of today, I strongly feel the pain of the
current architecture’s cracking and squeaking. Consequently, I believe that
we – the wider IETF community responsible for Internet technology – need to
re-think the architecture. We need to find a way to re-create the core of
the Internet in a way that leads to a new era of innovation and
intellectual prosperity....

... ( What we perhaps don’t consider very often is the fact that there are
huge asset values embedded in various parts of the network.)As the
slower-than-expected migration to IPv6 has amply demonstrated, some parts
of the current Internet are painfully hard to change. This makes any
long-term architectural thinking and planning difficult.

(While we can at most work towards understanding emergent complexity in the
first place, there is a great deal we can do about architectural
complexity... )

... We need some kind of an architectural vision and a related transition
path; an idea of where we are heading and perhaps how we could get there.

My vision includes peaceful co-existence of both IPv4 and IPv6 for a fairly
long time to come. While I would like to see a day when the last IPv4 node
is shut down, it is more likely that only future generations will see that
happening. In my vision it is possible to use any application I want
wherever I am and whatever kind of connection I may have. Indeed, I imagine
being able to use multiple wireless networks most of the time, and at least
one almost always. I dream of once more being able to communicate with
anyone, anywhere on the Internet, independent of the application we want to
use, not artificially hindered by NATs or other non-premeditated middle
boxes. Finally, in my vision we have baseline security as a built-in
feature of the architecture, providing cryptographically strong end-to-end
security and sufficient hooks for attaching different kinds of security
infrastructures, some based on organisational management and some based on
grassroots attempts to model interpersonal human trust relationships with
decentralised authorisation systems.

It looks very likely that fulfilling my vision requires adding a new layer,
a new “waist”, to the architecture [7]. We have to implement mobility,
multi-homing, and the envisioned baseline security somewhere in the stack.
If we want connectivity to span the partition between IPv4 and IPv6
networks, it looks necessary to build the functionality on the top of the
existing hop-by-hop functionality of the IP layer....

(Once we start to consider how to introduce the changes needed to progress
towards any vision, it becomes apparent that the two hardest-to-change
assets are the existing routing infrastructure and the set of all existing
applications. But network transparency is exactly what we should
re-establish...)

Using a term that Brian Carpenter recently coined, I propose that we aim at
providing new Architected Network Transparency (ANT). There seem to be
three or four potential migration paths towards ANT. One possibility is to
utilise a Cryptographically Generated Addresses (CGA) [8] based security
model in the IPv6 Site Multi-homing by Inter-Mediation (SHIM6) [9] to
provide end-to-end security and mobility even when IPv6 traffic is
shimmed....

... (Toward the ANT) One possible means might be Keyed Hash Identifiers
(KHI, pronounced as the Greek letter ?) [14], currently subject to heated
debate in the int-area and ipv6 mailing lists. Whether KHIs should be
considered as an important but transitory stepping stone or as despicable
opening of the flood gates to occupy the IPv6 address space with varmints
remains to be seen.

...".







Regard,
Guntur Wiseno Putra

Pada Kamis, 27 Februari 2020, Toerless Eckert <tte@cs.fau.de> menulis:

> On Wed, Feb 26, 2020 at 10:45:29AM +0000, Stephen Farrell wrote:
> > On 26/02/2020 10:21, Stewart Bryant wrote:
> > > "The head of MI5 has urged technology companies to give the security
> > > services â?????exceptionalâ???  access to encrypted messages
> >
> > And in other, equally shocking, news: the sun will rise tomorrow;-)
>
> https://en.wikipedia.org/wiki/The_empire_on_which_the_sun_never_sets
> ;-))
>
> > If you do want to rehash the cryptowars debate again,
>
> Not at all. But for example enterprises often use HTTPs proxies
> for firewalling, intrusion detection, proprietary data leakage
> prevention and the like. I am not aware we have stablished standards
> for such desirable behavior. In fact there are issues with the expected
> end-to-end krypto security when you bring in such trusted middle-men.
> (e.g.: undesirable cert spoofing). There are no browser standards
> for a three party trust-model AFAIK.
>
> Right now, we have only those global commercial players positioning
> them as trusted third parties. Even DoH IMHO falls into this play.
> And then selling customer data collected, at least when they have
> some entity operating outside europe (GDPR data leakage prevention).
>
> All those IoT devices that export unbeknownst do the user all type
> of collected user data to a cloud. We could come up with mandatory
> published data models, force the connection through a trusted third
> party device that can then do semantic filtering. Aka: i rather
> want to be able to control than just trust GDPR statements.
>
> Likewise i think we could define better behaving firewall policies
> in the fashion did it for NAT with BEHAVE, e.g.: more visibility
> of policy for better diagnostics.
>
> Etc. pp. Just brainstorm what positive evolution we could promote
> through IETF work for more security. The IETF end-to-end encryption
> laurels nice but not enough.
>
> > maybe at least change the subject line? If doing so,
> > and I hope you decide not to, because there's no gain,
> > please recognise that there are many (me included) who
> > do not share the views you quoted for sound technical
> > reasons (e.g. [1] is perhaps the most-cited recent
> > paper on that) that have garnered rough consensus in
> > the IETF every time we've done that rehashing.
>
> Stating that we would like to see IETF solve problems doesnt
> mean we agree to those regurgitated security agency memes.
> Instead, i see these memes as the real risks, because the
> public has shown to give in to the ongoing "tough on crime"
> pounding with really bad outcomes. So we really need better,
> alternative models for more security in addition to the
> ongoing push back against that type of nonsense.
>
> Cheers
>     Toerless
>
> > S.
> >
> > [1] Abelson, Harold, et al. "Keys under doormats: mandating insecurity
> > by requiring government access to all data and communications." Journal
> > of Cybersecurity 1.1 (2015): 69-79.
> > https://www.cs.yale.edu/homes/jf/paper-keys-under-doormats-CSAIL.pdf
> >
> >
> >
> >
> >
>
> pub   RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <
> stephen.farrell@cs.tcd.ie>
> > sub   RSA 4096/36CB8BB6 2017-12-22
> >
>
>
>
>
> > _______________________________________________
> > Architecture-discuss mailing list
> > Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
>
>
> --
> ---
> tte@cs.fau.de
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>