Subject: Checksum at IP layer - is it even needed ?

From: Alexey Eromenko <[email-masked]>
Date: Mon, 14 Dec 2015 17:38:32 +0200

In IPv4 and IPv6, pseudo-header mandates checksum at Layer 4, and also cover IP.

In IP-FF, I plan to remove "pseudo-header" from Layer 4 checksum, for
a few reasons:
1. IPsec ESP Transport mode over NAT-PT (NAPT). (one obstacle gets
removed, and I will deal with the rest later -- IPsec-NAT looks like a
can-of-worms for now)
2. ILNP protocol will become possible. (as an extension protocol)
3. better layer separation

...and I don't have checksum at Layer 3 either. (like in IPv6)

Do we actually need chcksums at Layer 3 ?
Disadvantages:
* Slow-down of Core Routers.

Do we even need IP-layer checksums ?
* Most Data-link layer protocols cover "data"; That is Layers 3-to-7
in CRC; one notable exception is ATM. Can I assume that layer 2 CRC
protects me ?
* a single mis-routed packet shouldn't cause too much trouble.
* in IPv6, the options / extensions are not protected by checksum
either. (not at layer 3, not at layer 4 -- maybe only at layer 2)

Any advantages ?
* prevents single mis-routed packets, or a bad option from getting through.

Quick analysis of Data-link layer's checksum protection:

ATM: Header-only, 8-bit.
Frame Relay: 16 bit.
Ethernet and WiFi - 32-bit FCS. (WiFi also has re-transmission)
Token Ring - 32-bit FCS
Point-to-Point Protocol (PPP) with 16 or 32 bits CRC.
4G/LTE: 24-bit CRC, +2nd level CRC.
Firewire IEEE-1394: 32-bit CRC.

Quick result: besides ATM, everybody else seems to cover both headers
and all data.
-- 
-Alexey Eromenko "Technologov"

---

From: Saku Ytti <[email-masked]>
Date: Mon, 14 Dec 2015 19:59:47 +0200

On 14 December 2015 at 17:38, Alexey Eromenko <[email-masked]> wrote:

Hey,

> * Slow-down of Core Routers.

Citation needed. I believe checksum and CRC are linerate and pretty
much free in terms of pincount, transistor and thermal.

> * prevents single mis-routed packets, or a bad option from getting through.

Prevents packet mangling, if done right. If there is L3 CRC (not
checksum, it's too weak) which excludes changing data (hop count) and
specification mandates that it's not recalculated on egress, but
ingress value is reused. Then it will guarantee that router or switch
does not mangle the data.

> Quick result: besides ATM, everybody else seems to cover both headers

Arbitrarily strong guarantee at L2 does not guarantee integrity at L3.
Routers and switches (not fibres/copper!) mangle data and calculate
correct L2 CRC on the broken data.
I've unfortunately seen[0] this several times in real networks and I
know other[1] networks who've seen it as well . I got lucky and was
using IPv4, which made the error visible in egress LER's, had I been
running IPv6 only, I would have never known that I'm mangling some
packets.

[0] http://mailman.nanog.org/pipermail/nanog/2014-January/063654.html
     https://www.ietf.org/mail-archive/web/tsvwg/current/msg12457.html
[1] http://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html

-- 
  ++ytti

---

From: Jared Mauch <[email-masked]>
Date: Mon, 14 Dec 2015 13:07:05 -0500

> On Dec 14, 2015, at 12:59 PM, Saku Ytti <[email-masked]> wrote:
> 

Yes, most hardware has offload in silicon for your desktop/wifi/ethernet
chipsets so the host doesn’t even do this.

> [1] http://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html

I’ve also seen this mangling in production, specifically with an employee
with backhaul over wireless equipment that corrupted the body of
a packet triggering downstream application bugs, eg:

https://www.debian.org/security/2011/dsa-2276

This is not that common, but does occur.  I’ve also seen similar issues
in OTN hardware that is unhappy with ethernet frames of certain sizes.

- jared

---

From: Alexey Eromenko <[email-masked]>
Date: Mon, 14 Dec 2015 23:14:23 +0200

Well, this is kinda unexpected.
I expected link failures (electromagnetic interference on copper
links), but we got device (middlebox) failures !

Now, if we want to protect vs. data mangling by middleboxes, we need
to look not only at switches, but also at NAT Routers (including cheap
home routers, and load-balancers) -- those *can* mangle any TCP data,
and compute the wrong checksum there !
Typical Internet data goes through NAT not once, but twice (!);  a
source NAT (a corporate firewall, or a home router), and then again
through a destination NAT (load-balancer).
Anyone of them can mangle data, if poorly implemented (cheap embedded
CPU without ECC cache, etc...)

One possible defense, is to modify TCPv5 and UDPv5 slightly, to
include CRC32 checksum, but only on the *data portion*, not on ports.
(instead of old 16-bit checksums)

Just moving to TCP/IP to CRC32 will *not* solve the issue of
middleboxes mangling our data.

But then port numbers are unprotected by checksum.
So data destined to port 20, can suddenly arrive to port 80.

Is this any better ?

A more radical idea, is to move "port numbers" to IP layer, and cover
them by IP-layer checksum, as nowadays "ports" are really "Routing"
data.

NOTE: I will be moving to "[email-masked]", so please subscribe there.
https://www.ietf.org/mailman/listinfo/5gangip

-Alexey "Technologov"

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 14 Dec 2015 16:45:20 -0500

> middleboxes mangling our data.

isn't the solution to all of this to just use TLS ? (or DTLS for udp)

---

From: Alexey Eromenko <[email-masked]>
Date: Mon, 14 Dec 2015 23:50:26 +0200

> isn't the solution to all of this to just use TLS ? (or DTLS for udp)

TLS/SSL is one solution; But there needs to be a solution for
unencrypted traffic also.

TCP is supposed to guarantee end-to-end reliability, but sometimes it
doesn't. (and with 2^16 checksums, at modern 1 Gig home links, it
really can't...)

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 14 Dec 2015 16:55:06 -0500

> unencrypted traffic also.

sure: "Move to encrypted traffic"

providing any real 'security' (or even 'people did not muck with my
packet') without real crypto is going to send the wrong message.

> doesn't. (and with 2^16 checksums, at modern 1 Gig home links, it

it SEEMS to work just fine... right? or did I miss the general up roar
from users who can't access internet things?

I suppose: "Why are we trying to solve this in tcp/udp? why not solve
this at the application layer with TLS?"

---

From: Saku Ytti <[email-masked]>
Date: Tue, 15 Dec 2015 00:02:29 +0200

> isn't the solution to all of this to just use TLS ? (or DTLS for udp)

Sort of. Or proper L4 like QUIC, MinimaLT. You'll know packet got
mangled, but troubleshooting which device it was is going to be hell.

-- 
  ++ytti

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 14 Dec 2015 17:34:59 -0500

> mangled, but troubleshooting which device it was is going to be hell.

So, one option is to go unscrew tcp/udp/IP and make checksums really
work for highspeed usage.. then packets get (if tossed at the IP
layer) at the hop which sees a failed packet checksum... however,
where would the router/switch/etc send the 'yer packet is cruddy' to ?
are you sure that the L3 data is correct at this point? why are you
sure? if a solarflare poked a hole in your packet, how do you know it
didn't poke 2 holes?

I don't think you can reliably figure out which hop caused your
problem :( so ... TLS  (or equivalent in QUIC/MinimalT/etc) is your
only real saving throw.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 14 Dec 2015 23:04:05 +0000

On 14/12/2015 21:55, Christopher Morrow wrote:
> this at the application layer with TLS?" . 
Yes, I was wondering about this.

If the content is not understood by anyone except the intended endpoint 
the occasional misdelivery is surely of no consequence.

Stewart

---

From: Saku Ytti <[email-masked]>
Date: Tue, 15 Dec 2015 01:16:43 +0200

> problem :( so ... TLS  (or equivalent in QUIC/MinimalT/etc) is your

If IP contains CRC for unchanging parts of data, and each hop verifies
it, but copies ingress value to egress value (not recalculate). Then
the very next hop of mangling device will notice the the problem.

When done on higher layer, it's invisible to the transport, we will
just have to accept that some router in some AS number mangled it, you
cannot get anyone to do anything to fix it.
Trying to call random AS helpdesk 'about 1 in 100k packets seem to be
mangled betweeen IP x and IP y'. For AS to figure out which one was
it, they'd need wire taps, it's LOT of work, and no guarantees to
succeed in determining faulty device unless src, dst and every transit
AS commits to solving it, i.e. it's not gonna happen unless it's
really really bad like 1 in 1000.

-- 
  ++ytti

---

From: <[email-masked]>
Date: Tue, 15 Dec 2015 00:32:08 +0000 (UTC)

> the occasional misdelivery is surely of no consequence.
There's still a risk of port pollution (IPv4) or destination pollution (IPv6)from misdeliveries without checksums.
not understood != not handled and pushed up the stack. 
 Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Stewart Bryant <[email-masked]>
 To: Christopher Morrow <[email-masked]>; Alexey Eromenko <[email-masked]> 
Cc: ietf <[email-masked]>; Jared Mauch <[email-masked]>
 Sent: Tuesday, 15 December 2015, 10:04
 Subject: Re: Checksum at IP layer - is it even needed ?

Stewart

---

From: Jared Mauch <[email-masked]>
Date: Mon, 14 Dec 2015 19:55:28 -0500

> On Dec 14, 2015, at 4:14 PM, Alexey Eromenko <[email-masked]> wrote:
> 

I’d like to be idealistic here, but the problem is fairly catastrophic and
widespread.  Things like UDP/5060 are badly mangled by ALG, including my
favorite that you can remotely reboot many of the AT&T Uverse boxes by
sending them SIP frames for devices through their ALG/NAT44.

Most home gateways have some broken ALG that actually makes things worse,
including when Cisco originally implemented SIP ALG and broke the original
Apple “iChat A/V” SIP messages from working properly.

The workarounds we’ve been slowly moving to is shifting services to alternate
ports that aren’t damaged by these transparent and helpful devices.  Our
instructions to users say “Turn off SIP-ALG” in your device, but things like
the carrier provided devices don’t expose these options depending on the
hardware revision, or just plain forget they have an internal interface for SIP
traffic and when you send them a check-config NOTIFY they consume it themselves
and crash/reboot.

I tried to report these problems, and captured many others when doing the
OpenResolverProject scans, including NATs that spoofed the source address
to their ALG-DNS ports/servers.  

Middle boxes are a giant unmitigated disaster of mostly consumer or
carrier provided devices that undergo zero testing and are part of
what I’ve dubbed the “IoT” (Internet of Trash) which will never be upgraded
or be administered.

What you have instead is everyone performing an effective overlay or plain VPN
around these devices that damage traffic.

	- jared

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Dec 2015 17:38:25 +0900

Jared Mauch wrote:

> ports that aren’t damaged by these transparent and helpful devices.

That is not a workaround, but the only proper solution, because, we can
do nothing against behavior of ALGs unknown to users, operators
or even manufactures of the ALG, other than avoiding the ALG.

And it can be automated if browsers support SRV, a DNS RR type to
specify non-default port numbers.

That's what I proposed in a position paper for an IAB workshop
of SEMI, but the paper was rejected with the following review comment:

: SRV in particular may work to confound assumptions about ports along
: the path, but many of the port-linked behaviors are under the control
: of the server operators anyway, so it is hart to see how this on its
: own would do much to restore end-to-endness.

That is, IAB is actively rejecting the idea of alternate ports.

						Masataka Ohta

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 15 Dec 2015 10:55:38 +0000

Lloyd

If that is a significant risk, then why did IPv6 not move
to a better protection when it was changing the other things
in the nw/xport interface? After all there were much
better c/s - such as Fletcher - that were well known
at the time?

Stewart

On 15/12/2015 00:32, [email-masked] wrote:
> There's still a risk of port pollution (IPv4) or destination pollution 
> (IPv6)
> from misdeliveries without checksums.
>
> ------------------------------------------------------------------------
> *From:* Stewart Bryant <[email-masked]>
> *To:* Christopher Morrow <[email-masked]>; Alexey Eromenko 
> <[email-masked]>
> *Cc:* ietf <[email-masked]>; Jared Mauch <[email-masked]>
> *Sent:* Tuesday, 15 December 2015, 10:04
> *Subject:* Re: Checksum at IP layer - is it even needed ?
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Alexey Eromenko <[email-masked]>
Date: Tue, 15 Dec 2015 13:22:32 +0200

I have evaluated separating TCP+UDP checksums from pseudo-header,
which gives some new applications:

1. ILNP - Identifier-Link Network Protocol.
2. IPsec-ESP-over-NAT-PT (one obstacle removed; not all)

But slows down other traffic by 0.4% (assuming 1000-byte packets) -
due to +4 bytes checksum at IP layer.
So separating checksums into TCP+IP layers has trade-offs, not a
simple improvement.

---

From: Jared Mauch <[email-masked]>
Date: Tue, 15 Dec 2015 08:00:35 -0500

> specify non-default port numbers.

	I'm not talking about a browser.

> That is, IAB is actively rejecting the idea of alternate ports.

	There is the constant problem of the internet is viewed
through the lens of a TCP{80,443} transport, but that's another topic.

	I'm talking about ALG that actively breaks things or exposes
the end devices to increased attack surfaces due to devices that will
never be properly maintained or are impossible to report defects against.

	I look at the work in DNSOP to document that queries over
TCP are acceptable, but you end up with devices where they will never
be upgraded and do this:

https://www.cloudshark.org/captures/273da18d3057

Returning REFUSED is certainly not the right policy choice here
for a home gateway device.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: <[email-masked]>
Date: Tue, 15 Dec 2015 13:26:54 +0000 (UTC)

Stewart,

we've recently had much discussion of this in tsvwg. (AndFletcher isn't that good...)

My working theory with hindsight is that, in many ways,IPv6 embodies the worst of all possible choices.
 Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Stewart Bryant <[email-masked]>
 To: [email-masked]; Christopher Morrow <[email-masked]>; Alexey Eromenko <[email-masked]> 
Cc: ietf <[email-masked]>; Jared Mauch <[email-masked]>
 Sent: Tuesday, 15 December 2015, 21:55
 Subject: Re: Checksum at IP layer - is it even needed ?
   
 Lloyd

 Stewart

 > the occasional misdelivery is surely of no consequence. 
  There's still a risk of port pollution (IPv4) or destination pollution (IPv6) from misdeliveries without checksums. 

 
 
 Stewart

---

From: Alexey Eromenko <[email-masked]>
Date: Tue, 15 Dec 2015 15:54:39 +0200

Look, if IPv6 had a 32-bit checksum,  it would increase their header by yet
another 4 bytes.  To a monster of 44 bytes.

This is a tradeoff - add those 4 bytes or let upper layer cover that one
for you...
And assume what-if IPFF has those 4 bytes covered. Should it also cover
"Hops" aka TTL, or not? Should it also cover data or not ?

And this will not prevent device mangling (moving to NAT devices this
time), instead of Ethernet switches.
On Dec 15, 2015 3:26 PM, <[email-masked]> wrote:

> My working theory with hindsight is that, in many ways,
> IPv6 embodies the worst of all possible choices.
>
>
> ------------------------------
> *To:* [email-masked]; Christopher Morrow <[email-masked]>;
> Alexey Eromenko <[email-masked]>
> *Sent:* Tuesday, 15 December 2015, 21:55
> ------------------------------
> *From:* Stewart Bryant <[email-masked]> <[email-masked]>
> *To:* Christopher Morrow <[email-masked]>
> <[email-masked]>; Alexey Eromenko <[email-masked]>
> <[email-masked]>
> *Cc:* ietf <[email-masked]> <[email-masked]>; Jared Mauch
> <[email-masked]> <[email-masked]>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Dec 2015 10:07:01 +1100

RFC 1123 said DNS/TCP is a SHOULD.  Most of the name servers in the
world actually implemented DNS/TCP.  All the stub resolvers in the world
actually implemented DNS/TCP.

The problem is that a myth grew up that DNS/TCP was only for AXFR so
people configured firewalls to block DNS/TCP as a way of blocking AXFR.

And there are others that turned the SHOULD into MAY when reading RFC
1123.

There were also a few CPE vendors that appear to have not read RFC 1123
because if they had I fail to see how they can justify not supporting DNS/TCP.

Then there are idiotic CPE vendors like the one below that outright lie to
DNS/TCP queries.  No where does any RFC permit that.

Mark

---

From: <[email-masked]>
Date: Wed, 16 Dec 2015 02:07:16 +0000 (UTC)

The question is 'checksum at IP layer - is it even needed'

I say 'yes' as a useful header check that packets are senttowards the correct destination at each hop; if the headersdon't pass scrutiny, don't bother. IPv4's headerchecksum covering mutable fields (TTL and QoS) maderecomputing at each hop painful and led to bizarre fixup checkbehaviour (discussed in detail on the tsvwg list); ifthat header checksum only covered non-mutable fields(and also overlapped pseudo header fields?) itwould have been imo (and that's likely a minority imo)better. Any cost to NATs which treat non-mutable fieldsas mutable is imo just a bonus to discourage NAT, really.

IPv6 leaving header checksums out in favour of assumingthat protocols would do the right thing with endpointpseudoheader checks has not worked well - see RFC6935and RFC6936 for hints of some of the consequences ofthat, or consider where UDP-Lite becomes useful andnecessary. But it makes NAT of IPv6 easier, so that'sthinking ahead!

In general, checksums and error detection are not wellunderstood in the IETF.

For example, DTNRG tried to design a protocolfor the most difficult errored conditions imaginable -and left out any error detection from it at all. (Seethe half-assed, half-baked RFC5050). Eight years afterthat problem was identified, 'find someone who understandschecksums to make a recommendation' is now a line item inthe RFC5050bis todo list in DTNWG meetings.

Choosing checksums to suit coverage lengths is nontrivial,because, you know, math. Math is hard, and the IETF is morearts and crafts of protocol specification, really.It's all basketweaving and handcrafted pottery and consensushums voicing approval of performance art. I mean,powerpoint slides.

L.

indaba hakuna matata ulwimi ululodwa alonelanga
 Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Alexey Eromenko <[email-masked]>
 To: [email-masked] 
Cc: ietf <[email-masked]>; [email-masked]; Christopher Morrow <[email-masked]>; Jared Mauch <[email-masked]>
 Sent: Wednesday, 16 December 2015, 0:54
 Subject: Re: Checksum at IP layer - is it even needed ?
   
Look, if IPv6 had a 32-bit checksum,  it would increase their header by yet another 4 bytes.  To a monster of 44 bytes.This is a tradeoff - add those 4 bytes or let upper layer cover that one for you...
And assume what-if IPFF has those 4 bytes covered. Should it also cover "Hops" aka TTL, or not? Should it also cover data or not ?And this will not prevent device mangling (moving to NAT devices this time), instead of Ethernet switches.

Stewart,

  
 Lloyd

 Stewart

  

 
 Stewart

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Dec 2015 15:55:58 +0900

> 	I'm not talking about a browser.

Sorry, browser is just an example and any application using domain
names can support SRV to avoid default port numbers contaminated by
ALGs. See below for examples of mail and name applications.

> never be properly maintained or are impossible to report defects against.

And using non default port numbers is the solution, for which SRV
and applications supporting SRV should be helpful.

> TCP are acceptable, but you end up with devices where they will never

The problem here is that a port number is implied by NS (and MX)
as I wrote in https://tools.ietf.org/html/draft-ohta-e2e-nat-00:

   A server port number different from well known ones may be specified
   through mechanisms to specify an address of the server, which is the
   case of URLs. However, port numbers for DNS and SMTP are, in general,
   implicitly assumed by DNS and are not changeable.

Still, in theory, SRV could be specified to override MX like:

	example.com     MX 0 mx.example.com
        _mx._tcp.mx.example.com  SRV 0 0 1000 mx0.example.com

and NS (often with glue As and glue SRVs) like:

	example.com NS ns.example.com
	_ns._udp.ns.example.com SRV 0 0 1000 ns0.example.com
	_ns._tcp.ns.example.com SRV 0 0 1000 ns0.example.com
	ns0.example.com A 192.0.2.1

Even in practice, as changes can be fully backward compatible
without any flag days, it is doable as a long term solution
against poor ALGs.

						Masataka Ohta

---

From: Saku Ytti <[email-masked]>
Date: Wed, 16 Dec 2015 11:44:21 +0200

> ALGs. See below for examples of mail and name applications.

Friends of SRV should read
https://tools.ietf.org/html/draft-lear-httpbis-svcinfo-rr-01

a) if we add SRV to browsers, we need to do +3 DNS lookup per resource
'for ever', SRVINFO will allow for 1 ultimately. In transition phase 3
is needed for any solution. But new protocol, like HTTP2 could be good
driver for new DNS RR.
b) it can announce all the transport protocols you're supporting (that
is, migration to new L4 does not add another DNS query, and migration
to new HTTP/SSH version is made easy)

-- 
  ++ytti

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 16 Dec 2015 10:53:37 +0100

On 16 Dec 2015, at 10:44, Saku Ytti wrote:

> a) if we add SRV to browsers, we need to do +3 DNS lookup per resource 'for ever'

We need to be careful with what and how we count.

As the author of the URI RR spec I was often shut down by people liking HTTP as they claimed URI would add the terrible extra round trip in DNS over UDP, when it in reality did save one roundtrip on top of TCP for a HTTP redirect (which HTTP people did not have anything against).

I.e. it very quickly turns into religion.

   Patrik

---

From: Alexey Eromenko <[email-masked]>
Date: Wed, 16 Dec 2015 12:02:19 +0200

I don't think a bunch of broken middleboxes need a new standard, like
SRV to change ports.
Those broken middleboxes can listen to those random ports via SRV, and
break them also...

It is not a solution. Really.
-- 
-Alexey Eromenko "Technologov"

---

From: Saku Ytti <[email-masked]>
Date: Wed, 16 Dec 2015 12:37:31 +0200

> It is not a solution. Really.

Sorry I got side-tracked, my like for SVCINFO has nothing to do with
broken middle boxes. It's about discovering all needed information to
correctly connect to needed service with one DNS query.
Imagine you deploy HTTPv2 server reachable only via QUIC in IPv6, how
will client figure out correct IP address, correct protocol version,
correct transport protocol on A/AAAA, SRV and SVCINFO? SVCINFO can
deliver that information in single query.

-- 
  ++ytti

---

From: Alexey Eromenko <[email-masked]>
Date: Wed, 16 Dec 2015 13:01:53 +0200

Checksum  goals in IPFF:

1. support for IPsec ESP NAT (+PAT)
2. ILNP
3. Device Mangling
4. be short

IPsec NAT, ILNP, Device Mangling, be short, be fast
ooooo

+++- IP-layer checksum + protects all data + TCP-layer checksum (data only)
++-+ IP-layer checksum + protects all data
+++- IP-layer checksum; header only + port + TCP-layer checksum (data only)
++-- IP-layer checksum; header only + TCP-layer checksum (data+port)
---+ TCP-layer checksum; covers IP pseudo-header (like IPv6)

We can't defend vs Mangling devices fully, sadly. (without encryption)
What if data-mangling device (NAT), changes port, and re-computes new
good checksum on it... ?
Server will accept a valid-data of a packet, that doesn't belong to the
session.

Basically, due to "shortness" requirements, it is hard to build better
checksums than in IPv6. (TCP checksum covers parts of IP)

Only thing, is that I consider upgrading IPFF TCP to CRC32, which will
take 4 more bytes of overhead.

ILNP-like concept can be done at transport-layer (like MP-TCP).

---

From: Saku Ytti <[email-masked]>
Date: Wed, 16 Dec 2015 13:51:08 +0200

> Server will accept a valid-data of a packet, that doesn't belong to the

Being self-centered bastard I don't care about NAT or other devices
which intentionally mangle packets. Protecting against them is not
priority to me. If the data mangling happens in Internet core, it
affects everyone, it's priority that those issues are recognised at
the next hop, so that it's easy to identify which node mangled it.
It's WAY smaller problem domain when you're faced with 'there are some
mangled packets' when everyone who complains happens to behind
specific NAT box. Compared to if it's some tier1 router is silently
mangling, complaints can come anywhere in the world, triangulating
that to one specific router in the world is slow and expensive (i.e.
not gonna happen).

-- 
  ++ytti

---

From: Alexey Eromenko <[email-masked]>
Date: Wed, 16 Dec 2015 14:26:47 +0200

> that to one specific router in the world is slow and expensive (i.e.

But if so, making a stronger layer 4 checksum can also solve this problem.
i.e. TCP with CRC32 or CRC64, instead of loosy 16-bit checksum.

It will solve the "core router" and the "important Ethernet switch"
mangling problem.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Dec 2015 22:00:46 +0900

> https://tools.ietf.org/html/draft-lear-httpbis-svcinfo-rr-01

The problem of SRV-like proposals is that they have too much
features not needed by most applications, among which, SRV is
least painful.

If I design a new RR, it would be:

	_<port>._<proto>.<domain> REDIRECT <altdomain> <altport>

where <port> and <proto> are in decimal.

> 'for ever',

With

only one DNS lookup is enough by answers with additional
records, which can be safely cached.

> SRVINFO will allow for 1 ultimately.

>From an implementer's point of view, fancy fields of <InstanceId>
and <Profile> are enough to abandon SRVINFO and URI is worse than
that because most applications can not treat most fields of
generic URIs.

> b) it can announce all the transport protocols you're supporting

Yes, all the transport protocols and all the services of a domain,
which are announced by SRVINFO RR of the domain.

That is a fatal defect of SRVINFO (and URI), because, if a domain
support 100 services with 2 transport protocols, there are 200
RRs, all of which must be replied for a single query, which is
unacceptably inefficient, which is why it is necessary to use a
service specific domain name for each service.

All the applications know which service they are offering and
almost all, if not all, applications including DNS, know which
transport protocol they are currently trying to use.

					Masataka Ohta

---

From: Saku Ytti <[email-masked]>
Date: Wed, 16 Dec 2015 16:00:46 +0200

> It will solve the "core router" and the "important Ethernet switch"

How? Core router wouldn't verify L4. Or is the proposal it should? So when
we introduce new L4, we need to update all L3 devices? Sounds like an
expensive layer violation.

-- 
  ++ytti

---

From: Alexey Eromenko <[email-masked]>
Date: Wed, 16 Dec 2015 16:03:32 +0200

> expensive layer violation.

It should not.
I say, that if TCP had a powerful checksum (like CRC32 or above),
Mangling problem would not occur at the Core Router level.

---

From: Saku Ytti <[email-masked]>
Date: Wed, 16 Dec 2015 16:03:59 +0200

> service specific domain name for each service.

Can and must are different things. Just because you can, does not mean
you should, must less that you must. Saying proposal is bad, because
you can do stupid things with it, is bizarre. I can have arbitrary
many A records for a name, does this mean A RR is bad as well? How is
SRV stopping you from creating stupidly large responses?

-- 
  ++ytti

---

From: Saku Ytti <[email-masked]>
Date: Wed, 16 Dec 2015 16:05:58 +0200

> I say, that if TCP had a powerful checksum (like CRC32 or above),

And you couldn't figure out who was mangling, only that packet was
mangled. Identifying and thus fixing the issue would be nearly
impossible, even for an operator who would want to fix it. Due to time
and cost involved in doing so.

-- 
  ++ytti

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Dec 2015 23:22:54 +0900

Saku Ytti wrote:

> you can do stupid things with it, is bizarre.

That's why I didn't assume 100 transport protocols.

But, it is stupid to forbid "https://example.com" and force using
"https://www.example.com", which means, in a long run, a domain
will support a lot of application protocols.

						Masataka Ohta

 I can have arbitrary

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 16 Dec 2015 15:40:59 +0100

> service specific domain name for each service.

Not URI as the owner for the URI is prefixed with the service and protocol.

The NAPTR do have a RRSet that blows up in size when you have multiple services etc.

NAPTR have a design where a domain name announces what services it can handle.

URI have a design where you look up what you want given you already know what service you are after.

This is why for example I personally think NAPTR is broken for ENUM and URI would have been better. And due to the higher efficiency why I think URI is better than "HTTP redirect via well-known-url".

   Patrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 16 Dec 2015 15:42:16 +0100

> will support a lot of application protocols.

This is why the URI would be:

_http._tcp.example.com.     IN URI 1 1 "https://www.example.com/"
_http._tcp.www.example.com. IN URI 1 1 "https://www.example.com/"

Etc...

   Patrik

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 17 Dec 2015 16:12:36 +0900

> Not URI as the owner for the URI is prefixed with the service and protocol.

My misunderstanding, sorry.

> And due to the higher efficiency why I think URI is better than "HTTP
> redirect via well-known-url".

HTTP redirection redirects an entire URL to another URL and is well
defined.

However, though rfc7553 states:

   but instead of returning a hostname and port
   number, the URI record returns a full URI.  As such, it can be viewed
   as a more powerful resource record than SRV.

URI RR can not be used by applications without URL specifications,
whereas SRV can be used by any applications using hostnames (and
having IANA registered (or, well known?) service name).

Worse, even with applications with URL specifications, what happens
if the following URL:

	<scheme0>:<userinfo0>@<host0>:<port0><path0>?<query0>

invokes URI query using <scheme0> and <host0> results in:

	<scheme1>:<userinfo1>@<host1>:<port1><path1>?<query1>

How the original and the resulting components can be combined?
Obviously, scheme and host will be replaced, but how other
fields should be combined/replaced?

SRV is already bad with port numbers, which I addressed
in draft-ohta-urlsrv-00.

					Masataka Ohta

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 17 Dec 2015 09:06:21 +0100

> having IANA registered (or, well known?) service name).

If you as an application query for a specific service, you should be prepared to receive all URI schemes that can be used for that service.

I.e. if you query for _http._tcp.example.com. it would be confusing and weird if you get a SIP-URI scheme back.

And if you get one you do not understand, throw it away.

It is similar to get a redirect in HTTP to a URI scheme you can not handle.

   paf

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 17 Dec 2015 18:49:11 +0900

Patrik Fältström wrote:

> If you as an application query for a specific service, you should be prepared
 > to receive all URI schemes that can be used for that service.

What if there is no URL scheme that can be used for that service?

 > 	I'm not talking about a browser.

don't assume all the applications are living in HTTP world and have
URLs to describe the applications.

> I.e. if you query for _http._tcp.example.com. it would be confusing
 > and weird if you get a SIP-URI scheme back.

Suppose that there is no http scheme defined, in which case, no
URL could be returned from the beginning.

For example, what URL could be placed at "_domain._tcp.example.com"?

						Masataka Ohta

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Dec 2015 11:01:11 -0500

--On Wednesday, December 16, 2015 15:42 +0100 Patrik Fältström
<[email-masked]> wrote:

>> But, it is stupid to forbid "https://example.com" and force
>> using "https://www.example.com", which means, in a long run,
>> a domain will support a lot of application protocols.
> 
> _http._tcp.example.com.     IN URI 1 1
> "https://www.example.com/" _http._tcp.www.example.com. IN URI
> 1 1 "https://www.example.com/"

Especially because there are a good number of very sound
reasons, especially when one looks a very large domains with
many hosts and their own deep hierarchy and at assorted IDN
label cases, why one would not want example.com to be a synonym
for www.example.com.  In other worse, it is not as obviously
"stupid" as Masataka's comment suggests.

   john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 Dec 2015 11:23:47 -0500

> DNS/TCP queries.  No where does any RFC permit that.

This gets back to the earlier discussion on 'red lines'.

DNS was designed in a different age, at a time when nobody knew what
they were doing because it was research. Some architectural principles
I draw from the design of the DNS are:

1) The architecture anticipated the use of local resolvers at an early
stage, the protocol should have reflected this. The client-resolver
protocol should have been considered separately from the
resolver-authoritative protocol.

2) Don't expect a protocol to be able to use TCP as fallback for UDP.
Pick one or the other.

3) When using UDP to a stateless server, requests cannot be longer
than a single packet but multipacket responses are possible.

4) Don't put arbitrary size limitations in specifications.

Yes, having users really sucks. They do things to suit their
particular needs and then they expect future protocol changes to
support their activities. The only thing worse than having users is
not having users.