Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

[Joe Touch <[e-mail]>]

Hi, Tom, 

On 2019-01-17 07:27, Tom Herbert wrote:

> On Thu, Jan 17, 2019 at 7:06 AM Joe Touch <[e-mail]> wrote: 
> Hi Tom,
> 
> On Jan 17, 2019, at 6:55 AM, Tom Herbert <[e-mail]> wrote:
> ...
> 
> As I mentioned, in-network reassembly has not been specified, only
> reassembly at end destinations has been. 
> Hint - if a packet arrives on your interface with your IP address, you ARE a host.
 Joe,

Conversley, if a packet arrives on your interface that isn't destined
to your IP address, you ARE NOT a host. 

Correct. Note that the association of host with traffic counts for both
transmission and reception, though. 

> I suspects that
> implementations of in-network reassembly commonly make two incorrect
> assumptions: 
> The first one is above... 
> 1) All fragments of a packet traverse the network device performing reassembly
> 2) The first fragment is always received first
> 
> Neither of these assumptions are valid for IP. 
> Agreed, but again, there are three incorrect assumptions. The first is that a NAT isn't a host, and too often that's the one that causes the above two to actually cause pain.
 If NAT is a host, then it is only a host in the return path. Packets
sent from the client behind a NAT have destinations addresses that are
not those of the the NAT device. If a device is performing host
procedures on such packets, like reassembly, then it is being done
outside the auspices of the standard. 

Not quite. The return path is certainly easier to see, but the forward
path doesn't *relay* the incoming packets; it consumes them. Which is
what a host does. 

The outgoing packets are emitted with the source IP of the NAT. So in
the forward direction, strictly, only the *content* is relayed. 

If that content is modified (i.e., address/port rewriting) or inspected,
then that device is acting as a host. 
If the outgoing HOST packets depend on something of the incoming ones,
then that device is also acting as a host. 

> In any case, this isn't a NAT specific issue. Stateful firewalls
> regularly process packets for which they aren't the destination.

And they are similarly bound by the rules of being a host *when they
do*. 

The Internet requirements work just fine; its the devices that aren't
following them. 

Joe