. That is, DNS is
not fully responsible for the problem.
However, it is almost certain that the zones will have poor
administration and, thus, poor security even if DNSSEC were
deployed.
Masataka Ohta
___
Ietf
the server back to the querying entity?
As DNSSEC is not protected from MitM attacks on zones on the path
between client and server zones, how can you expect plain old DNS
is better protected?
Masataka Ohta
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
the query.
That's not a new cryptographical problem.
As DNSCurve protection is like DH, it is subject to MitM attacks,
which is no different from simple nonce.
Masataka Ohta
___
Ietf mailing list
Ietf
secure.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
and packet snooping impossible, which means you must
say simple nonce secure.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
that the security you
observe is not of SSH but of return routability.
Return routability over many third party ISPs is not 'verifiable',
of course.
Masataka Ohta
___
Ietf mailing list
Ietf
. This is slightly different from plain DH.
No, it is not expected that gtld servers will become
???.gtld-servers.net,
only to cause message size overflow.
Masataka Ohta
. If relying on security of root and other zones, which are
not really secure, was seriously considered, there should be
provisions for more complex mechanisms such as key roll over to
make the system a little less insecure.
Masataka Ohta
Phillip Hallam-Baker wrote:
Once you have established an SSH relationship
That's the (lack of) security of SSH by return routability. PERIOD.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https
, is not
infallible, which is why PKI is insecure.
Is EV divine?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
cryptography,
though I don't prefer it.
But, later, I noticed fundamental fraud in PKI, against which no
technical solution exists. Note that separation of ZSK and KSK
was an impossible attempt make inherently insecure PKI less
insecure.
Masataka Ohta
at all.
That's all.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
characters.
Note also that the wrong conversion is by Tim Bray who says:
I will commit to offering some cycles to help with tools
and specs, as appropriate.
How much reliability, do you think, the tools and specs will have?
Masataka Ohta
for pdf:Creator.
Thank you for a convincing demonstration to deny yourself.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
in
this file with the high bit set, if we want to bring that up too.
As we are discussing about text format, let's ignore PDF. PERIOD.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https
able to interpret them in 1000 years
Then, we should use a format available at least 500 years ago.
Were you using HTML 500 years ago?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https
/edit their local characters.
People can't read/edit local characters of other people.
HTML is already too complex and unstable that there is no hope that
UNSTABLE?
Is it still version 1.0?
Please elaborate.
See above.
Masataka Ohta
Phillip Hallam-Baker wrote:
As was discussed already in this ML, RPKI is useless.
Even if an AS owning an address block is securely known, it does
not secure routing to the address block through other ASes.
Masataka Ohta
in a
claimed-to-be-pure-ASCII PDF.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
?
Or?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Phillip Hallam-Baker;
I can understand that you are seriously worrying about archaeology
of year 3010 and beyond.
However, I'm afraid no one else is interested in.
Masataka Ohta
___
Ietf mailing
was demonstrated at all.
Again, it's your problem.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
?
But, broken definition is worse than broken tools, which, even
more strongly, means we must not use profiled subset.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman
, it will be reached in year 3010 or later.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
character encoding could have
been internationalized.
Moreover, for these 10 years, I have developped a simple and straight
forward theory on what, actually, is unification. I can elaborate, if
you are interested in.
Masataka Ohta
names can't use
non-ASCII for more serious purposes such as mail addresses, if
they want to receive mails internationally.
Masataka Ohta
PS
My children know ASCII characters not by birth but by education in
an elementary school, which, I think
to deliver. They also may actually become victims of the
language barrier
No English. OK. And, Japanese is the best language, of course. Let's
not use English but Japanese, internationally. OK?
Masataka Ohta
, does not
help here.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
If you need really international scope, pure ASCII is the only
choice.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
and
the fundamental solution is to loosen the requirements at least
for IDs.
With regard to the subject, introduction of non-ASCII characters
will make the matter a lot worse.
Masataka Ohta
___
Ietf mailing
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
expertise to use Latin, Greek and
Cyrillic characters only.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
can't fully predict how disastrous
full deployment of unicode could be.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
better things would
be if they had stuck with ISO 2022 instead?
See above.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Heavy use of NAT causes lots of problems and will continue to.
End to end NAT is a form of port restricted IP without any
problem of legacy NAT.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https
.
multihomed hosts.
As the proper support for multihoming needs careful and fundamental
design at the IP, transport and application layers, latter tweaking
of DS or DS-light can not be useful.
Masataka Ohta
to replicate requests otherwise. It certainly
isn't impossible to do.
Sure. What is necessary is clear documentation of DHCP/PPP
extensions and gateway-client protocols.
Masataka Ohta
___
Ietf mailing list
TCP, which send multiple SYN to several addresses
of a peer helps a lot to reduce timeout.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
While legacy NAT is a form of port restricted IP, lack of end to
end transparency is still a problem.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to addresses, they should be happy to use it.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
need to break the idea that a Web service should have a URL
that starts HTTP.
Try https.
Under the covers this would of course expand via SRV to a http URL,
SRV answer gives port numbers and addresses, not a URL.
Masataka Ohta
complex
and, thus, difficult, if not impossible, than plain old DNS).
The end to end security can be established only by sharing a security
information directly and securely by ends without any intermediate
entities such as CAs.
Masataka Ohta
.
Congratulations for the historic moment.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
again
for details.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Does DNSSEC Come In?
DNSSEC secures the name to address mapping
Transport and Application security are just other layers.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https
NAT capability.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
or 1000, there is no point to migrate to old and poor
IPv6, even if we need a long term solution.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
the beginning.
It's inherent to fundamental architecture of the CATENET model.
You can find more than two levels of aggregation in RFC796.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org
is in IPv6 with ID/locator
separation, same is doable with (port restricted) IPv4.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
including NAT64 is denied,
mathematically and logically.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ID for his favorite RSVP is unnecessary, because QoS capable
L2s have its own label.
There may be other simplifications possible.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org
to more configurations.
See above.
It should be largely advertised that, v4-v6 transition HAS started
(fortunately, not everybody is lagging behind):
It has been starting for these 15 years.
Masataka Ohta
and edge ISPs by end to end
NAT gives you the environment you want.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to introduce jumbograms,
such computers have I/O subsystem, which can take care of TCP
without bothering main CPUs.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
is used as a 2B source and a 2B destination port numbers.
until RFC 3948 came along in 2005. Since then, even the weak form of
the more secure myth has been indefensible.
IP over TCP is a more robust kludge for legacy NAT.
Masataka Ohta
model to offer IPv6 service while dealing with the IPv4
address shortage, IT IS a deployable approach.
For some ISPs, it has a very good performance/cost ratio.
That's an argument similar to ones heard for these 15 years.
Masataka Ohta
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
exist, it is impossible that CPEs operated by subscribers
determine the length of telephone numbers.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
of queries
could be saved.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
by the Internet, and will eventually disappear.
At that time, most of the features of VoIP protocols will
become obsolete.
and e164.arpa. will be obsolete.
Masataka Ohta
___
Ietf mailing list
Ietf
callers number, which is trusted upon by most mobile phone
users.
You can just trust network and domain operators of the Internet,
just as you can trust network and E.164 number operators of PSTN.
Masataka Ohta
?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to maintain E.164 for
POTS.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
subaddresses.
Remember also that the delay occurs for all the calls even though
virtually no one is using the subaddresses.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
systems
deploy some security protocol.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
that ICMPv6,
regarded as an application, could be secured by IPsec, which,
of course, is untrue. People tend to think PKI works magically.
Masataka Ohta
PS
Port restricted IPv4, including end to end NAT, is transparent
to IPsec, as long as SPI can
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
the Internet using IPsec
with transport mode?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
as IPv6 security myth.
It is of course that IPsec tunnel mode is used by IPv4 and/or
IPv6 VPN gateways.
But it does not make IPv6 more secure than IPv4.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to be
authenticated by IPsec through the hypothetical universal PKI.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
of features in order to encourage
transition to IPv6 has been tried for the past ten years and utterly failed.
So true.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo
Jari Arkko wrote:
NAT/FW traversal is also important even
with IPv6, as you may have a firewall even in IPv6 (or be going through
a NAT64).
FYI, traversable firewall is, by definition, broken.
Masataka Ohta
what happened to path MTU discovery.
Just as path MTU discovery for IPv6 won't work, you can't expect
firewalls in the real world behave friendly to your own firewall
traversing protocols.
Masataka Ohta
need is to enable, but NOT MANDATE, complete end to end
transparency.
It is of course that end to end connectivity can be blocked
by firewalls.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https
the vendors. It might not work with some bargain basement
home router you get at Wallmart, but even they eventually get
updated software.
According to your theory, a universal NAT traversal protocol
should already exists.
Masataka Ohta
and is much better than HTTP CONNECT
because of UDP.
So, we are done.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
(dual stacking was abandoned).
On the other hand, IPv4 address space extended by PR-IP (port
restricted IP such as Address+Port, end to end NAT and port
enhanced ARP) is large enough and the end to end connectivity
is always kept.
Masataka Ohta
and is no special.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
routers.
If we write a draft on IPv6 issues, it should contain a lot
more and a lot more serious issues than those of shared
addressing.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
an address have the same location,
much more safely than assume hosts in a /24 address range have
the same location.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
which ports are
available, right?
My implementation of PRIP has such mechanisms as ioctl.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to
a physical location using information from the network
infrastructure.
AFAIK, IP addresses can not be used for high fidelity geo-location,
though some copyright-wraiths are hoping so.
Masataka Ohta
).
Directional antenna makes it imprecise.
Is it a use case in the real world?
The US FCC thinks so:
http://edocket.access.gpo.gov/2011/pdf/2011-565.pdf
Could you quote the relevant part of the lengthy document?
Masataka Ohta
of the experiment?
Masataka Ohta
PS
I acknowledge there is no real world use cases.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
directives of structured text such as:
.in +3
...
.in -3
when necessary.
But, when plain text is good enough, we use plain text.
Assuming you have ASCII key board, 80-column assumption is
reasonable.
Masataka Ohta
there's an actual, real crisis on top of us.
That's so true for you and other people insisting on IPv6.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
on PubMed, IEEE, ACM, google scholar etc.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Eric Burger wrote:
time = money
Yes.
It is a lot more time (and money) saving to search free
versions before entering transactions to purchase them than
to rely blindly on PubMed, IEEE, ACM, google scholar etc.
So?
Masataka Ohta
301 - 400 of 522 matches
Mail list logo
