Subject: [MBONED] WGLC for <draft-ietf-mboned-auto-multicast-08.txt> - UDP checksum?

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 27 Nov 2007 08:12:11 +0000

Glad to see AMT progressing. I have some comments on the draft.

The UDP checksum is the primary way of validating correct endpoint
selection - i.e. this endpoint on this host was the intended recipient. 
This is needed to offer some basic protection to the receiving stack at 
whichever host this packet is finally delivered to (even if corrupted 
and/or mis-routed - albeit with 1/64k chance of a mistake). Setting it 
to zero can lead to other hosts/apps receiving packets with errors or 
the wrong payload - although they may not expect to receive these, nor 
have any way of detecting this.

---
1) In section  6.1:
"The UDP checksum MUST be valid in AMT control messages."
- Agreed, but what does valid mean? (This is echoed in 6.2, 6.3, 6.4)

I would expect that the transport-layer checksum is the responsibility 
of the transport layer. All stacks MUST set a valid UDP checksum on 
transmission and MUST reject datagrams that do not have a valid checksum 
on reception.
---
2) I do not agree with section 6.6 for IPv4:
"The UDP checksum SHOULD be 0 in the AMT IP Multicast Data message."

In the case of IPv4, this is not good practice. It would be bad practice 
to encourage widespread deployment of a new protocol that disables the 
UDP Checksum. I think the tunnel SHOULD enable UDP checksums, as in
[draft-ietf-tsvwg-udp-guidelines-04.txt].
---
3) The above recommendation in section 6.6 goes against the design 
rationale for IPv6, a Draft Standard (RFC2460), and seeks to update it. 
This is inappropriate. IPv6 applications MUST enable UDP checksums 
(there is no option offered).
---
4) The document does not cite RFC2460, which I would have expected as a 
normative reference for IPv6 use of UDP. RFC2119 is also normative.
---

Best wishes,

Gorry

_______________________________________________
MBONED mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mboned

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 Nov 2007 00:33:28 -0800

> selection - i.e. this endpoint on this host was the intended  
> recipient. This is needed to offer some basic protection to the  
> receiving stack at whichever host this packet is finally delivered  
> to (even if corrupted and/or mis-routed - albeit with 1/64k chance  
> of a mistake). Setting it to zero can lead to other hosts/apps  
> receiving packets with errors or the wrong payload - although they  
> may not expect to receive these, nor have any way of detecting this.

First off the AMT UDP encapsulation is an outer header, used between  
the Relay and Gateway. The multicast data within is protected.

Second, all AMT control traffic is UDP checksum protected. Only the  
Data Message is not because we don't want AMT Relays to have to  
checksum the entire packet at forwarding time. It is actually  
impractical to do so and is not necessary. There is CRC support most  
likely on every data link between the Relay and the Gateway, so if  
there are bit errors, the packet is dropped by an intermediate framer  
along the path.

So I think it is in everyone's best interest to require AMT Data  
Messages to be transmitted with a UDP checksum of 0. And hence, why  
the spec reflects this.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 Nov 2007 00:33:28 -0800

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 Nov 2007 18:02:36 -0800

>>> Only the Data Message is not because we don't want AMT Relays to  
>>> have to checksum the entire packet at forwarding time. It is  
>>> actually impractical to do so and is not necessary. There is CRC  
>>> support most likely on every data link between the Relay and the  
>>> Gateway, so if there are bit errors, the packet is dropped by an  
>>> intermediate framer along the path.
> I am not sure what you mean by impractical to conform to RFC2460.

Forwarding rates will slow to a crawl if a router has to walk every  
byte of packet during forwarding time (when it is decapsulating an UDP  
encapsulation).

> The case you cite does not address the issue of datagrams that  
> arrive at an endpoint that is different to that which the source  
> intended (as above).

If this occurs because of a bit reset in the destination IP address,  
then a data-link CRC will find it and the packet will be dropped by  
the first intermediate device after the reset device.

And one would have to question, why the IP layer in the destination is  
passing packets to the transport layer when it is not it's own address.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 Nov 2007 18:02:36 -0800

Dino

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 28 Nov 2007 08:19:33 +0000

Dino Farinacci wrote:
> Forwarding rates will slow to a crawl if a router has to walk every byte 
> of packet during forwarding time (when it is decapsulating an UDP 
> encapsulation).
> 
Understood, but a natural ramification of using an end-to-end transport 
protocol as a tunnel mechanism is that you need to comply with the spec. 
That was a design choice, over using other tunnel encapsulations. If you 
want to change the UDP spec., we should talk about this in transport area.

>> The case you cite does not address the issue of datagrams that arrive 
>> at an endpoint that is different to that which the source intended (as 
>> above).
> 
> then a data-link CRC will find it and the packet will be dropped by the 
> first intermediate device after the reset device.
> 
And could it be that the error occurs within a DMA/copy or memory 
internal to a router/interface/host-stack?

> passing packets to the transport layer when it is not it's own address.
The endhost with the destination that matches the IP address will.

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 28 Nov 2007 08:19:33 +0000

Gorry

---

From: "Greg Shepherd" <[email-masked]>
Date: Wed, 28 Nov 2007 09:14:20 -0800

> want to change the UDP spec., we should talk about this in transport area.

I don't think anyone is suggesting changing the UDP spec. But perhaps
the spec, when written, didn't conceive of intermediate encapsulation
nodes where applying another checksum would be prohibitively slow and
redundant/unnecessary. Would this warrant a transport area draft for
applications/extensions to UDP? I'd hate to have AMT held up for this.

> internal to a router/interface/host-stack?

And the internal checksum on the original data packet will still do
it's job here.

> The endhost with the destination that matches the IP address will.

Sorry, you both lost me here.. :-)

Greg

---

From: "Greg Shepherd" <[email-masked]>
Date: Wed, 28 Nov 2007 09:14:20 -0800

Greg

---

From: John Zwiebel <[email-masked]>
Date: Wed, 28 Nov 2007 09:29:00 -0800

> Sorry, you both lost me here.. :-)

Dino is saying: "Why would a router look at the UDP section since the  
packet isn't
   addressed to the router?"

Gorry is saying: "The end host looks at it"

In other words, they aren't communicating.
;-)

---

From: John Zwiebel <[email-masked]>
Date: Wed, 28 Nov 2007 09:29:00 -0800

---

From: Pekka Savola <[email-masked]>
Date: Wed, 28 Nov 2007 19:36:27 +0200 (EET)

> applications/extensions to UDP? I'd hate to have AMT held up for this.

If AMT wants to disable checksumming, it should use UDP lite, but then 
again, that wouldn't pass NATs so it's a non-starter.

So, I guess the only option is enabling checksumming.

I can predict that any attempt to change transport area's opinion 
about this is pretty much doomed to fail and are a waste of effort. So 
I'd forget about writing drafts.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Wed, 28 Nov 2007 19:36:27 +0200 (EET)

---

From: "Greg Shepherd" <[email-masked]>
Date: Wed, 28 Nov 2007 09:40:47 -0800

> In other words, they aren't communicating.

Okay, that was my suspicion. :)

---

From: "Greg Shepherd" <[email-masked]>
Date: Wed, 28 Nov 2007 09:40:47 -0800

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 28 Nov 2007 17:53:56 +0000

> applications/extensions to UDP? I'd hate to have AMT held up for this.
I think "redundant" and "unnecessary" need to both be examined, it looks 
like this needs thought.

> And the internal checksum on the original data packet will still do
I think we are still at cross purposes, let me try a simple IPv6 example 
shows one of the possible pathologies:

Tunnel endpoint sends A packet Encapssulated in a UDP datagram intended 
to tunnel endpoint A port B.

The packet header is changed somewhere to address C on port D. Routers 
now forward the packet to unexpected destination C. C now receives the 
packet on port D.

How does C know to drop the packet or not? The IP pseudoheader in IPv4 
would have been checked if C had implemented UDP as specified by the RFC 
for IPv6. If you change the UDPv6 stack to disable the checksum, you 
can't figure this out (it accepts the tunnel packet as opaque data, it 
is irrelevant what the payload of the UDP datagram contains).

Sender --> Tunnel In --+----+----+> Tunnel End (A) --> Expected dest
                             |
                          Unexpected recipient (C)

"+" routers on tunnel path.

> Sorry, you both lost me here.. :-)

I'll be starting my travel to Vancouver tomorrow, but promise to request 
some wider transport area review next week.

Best wishes,

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 28 Nov 2007 17:53:56 +0000

Best wishes,

Gorry

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Nov 2007 11:05:55 -0800

> Dino is saying: "Why would a router look at the UDP section since  
> the packet isn't

No, not true. In the case of AMT, the packet is addressed from the AMT  
Relay to the AMT Gateway.

> Gorry is saying: "The end host looks at it"

True.

> In other words, they aren't communicating.

Not true.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Nov 2007 11:05:55 -0800

True.

Not true.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Nov 2007 11:14:55 -0800

>> byte of packet during forwarding time (when it is decapsulating an  
>> UDP encapsulation).
> Understood, but a natural ramification of using an end-to-end  
> transport protocol as a tunnel mechanism is that you need to comply  
> with the spec. That was a design choice, over using other tunnel  
> encapsulations. If you want to change the UDP spec., we should talk  
> about this in transport area.

UDP has been used by routers for decades (i.e. RIPv1). It is not just  
an end-to-end (I think you are implying it's a host-to-host) protocol.

We don't have to change the UDP spec, it says that a checksum of 0 is  
legal. What the UDP spec doesn't say is that you do this differently  
for IPv4 versus IPv6 (for obvious reasons that UDP was created before  
IPv6 was).

It's RFC 2426, which decided to override the UDP specification.

So AMT for IPv4 is compliant with the text written in the UDP spec.  
The issue is solely for IPv6.

>> If this occurs because of a bit reset in the destination IP  
>> address, then a data-link CRC will find it and the packet will be  
>> dropped by the first intermediate device after the reset device.

ECC, parity, and CRC internal to the box usually find these things.

>> And one would have to question, why the IP layer in the destination  
>> is passing packets to the transport layer when it is not it's own  
>> address.

Like I said, a CRC on a data link will find this. It's not a problem.  
It was in the 70s because data link checksumming was weak and hence  
the original IP designers felt they needed something stronger so they  
built the pseudo-header checksum.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Nov 2007 11:14:55 -0800

Dino

---

From: Stig Venaas <[email-masked]>
Date: Wed, 28 Nov 2007 20:24:21 +0100

Dino Farinacci wrote:
> UDP has been used by routers for decades (i.e. RIPv1). It is not just an
> end-to-end (I think you are implying it's a host-to-host) protocol.

You might say that from UDP perspective the tunnel end-points (AMT
Relays and Gateways) are hosts.

> legal. What the UDP spec doesn't say is that you do this differently for
> IPv4 versus IPv6 (for obvious reasons that UDP was created before IPv6
> was).
> 
> So AMT for IPv4 is compliant with the text written in the UDP spec. The
> issue is solely for IPv6.

Right, for IPv4 you compute checksum for the IPv4 checksum header. For
IPv6 you instead have a transport checksum that include some of the IPv6
header fields in the computation. So, for both you have to compute a
checksum, it's just two different ones.

Stig

> Like I said, a CRC on a data link will find this. It's not a problem. It
> was in the 70s because data link checksumming was weak and hence the
> original IP designers felt they needed something stronger so they built
> the pseudo-header checksum.
> 
> Dino
> 
>

---

From: Stig Venaas <[email-masked]>
Date: Wed, 28 Nov 2007 20:24:21 +0100

Stig

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Nov 2007 22:24:23 -0800

> checksum, it's just two different ones.

But CRCs are much stronger than the 1's complement checksum in the IP  
and transport headers.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Nov 2007 22:24:23 -0800

Dino

---

From: Stig Venaas <[email-masked]>
Date: Thu, 29 Nov 2007 07:39:37 +0100

> But CRCs are much stronger than the 1's complement checksum in the IP

Agree. I guess I should also add that the IPv4 header checksum is easier
to compute than the transport checksum in IPv6.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 29 Nov 2007 07:39:37 +0100

Stig

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Nov 2007 22:39:24 -0800

> to compute than the transport checksum in IPv6.

That is definitely true. It typically is over a fixed number of bytes  
(i.e. 20) which tend to always be in a high-speed FIFO.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Nov 2007 22:39:24 -0800

Dino

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 29 Nov 2007 09:51:31 -0500

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]] 
> Sent: Thursday, November 29, 2007 1:39 AM
> To: Stig Venaas
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MBONED] WGLC for 
> <draft-ietf-mboned-auto-multicast-08.txt> -UDP checksum?
> 
> >>> Right, for IPv4 you compute checksum for the IPv4 
> checksum header.  
> >>> For

Who knew that we would miss the IPv4 header checksum so much?

Problem is, going between different link layers, you don't always have
the protection of a link layer's CRC. Bits can get switched at
inconvenient times.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 29 Nov 2007 09:51:31 -0500

Bert