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

[Tom Herbert <[e-mail]>]

On Thu, Jan 17, 2019 at 8:24 AM Joe Touch <[e-mail]> wrote:
>
> 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*.
>
Joe,

That's impossible. The first rule is that a host is defined as a node
to which packets are addressed. Intermediate nodes performing host
processing on packets that don't have their address have already
violated rule #1. If they're keeping flow state in the network
(connection state or reassembly), then that inevitably forces the
requirement that packets have to be routed through a particular node
in order for state to be maintained. This is not a problem hosts have,
and it's not required in IP that packets of a flow have to always take
the same path to a destination. Without additional requirements on
deployment, stateful devices break multi-path.

So if these devices need to *emulate* host behaviors then there really
should be a specification to that effect. It's not enough to simply
say they have to follow host requirements. They can't and they clearly
impose additional requirements.

Tom

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