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

[Tom Herbert <[e-mail]>]

On Thu, Jan 17, 2019 at 12:48 PM Joe Touch <[e-mail]> wrote:
>
> Hi, Tom,
>
>
>
>
> On 2019-01-17 08:58, Tom Herbert wrote:
>
> On Thu, Jan 17, 2019 at 8:24 AM Joe Touch <[e-mail]> wrote:
>
>
> ...
> 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.
>
>
> A second rule - per RFC 1812 - is that forwarding devices modify only the opcount and certain IP options.
>
>
>
> Intermediate nodes performing host
> processing on packets that don't have their address have already
> violated rule #1.
>
>
> They consume those packets, they are acting as if they think all outgoing dest addresses are theirs and assigned to their interface. I.e., from the outside, they act exactly as if their interface has ALL those addresses.
>
>
> 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.
>
>
> Agreed. And because they act as host, they fail badly when they're not deployed under host assumptions and requirements.
>
>
>
> This is not a problem hosts have,
>
>
> It is - that's implicit in the function of their reassembly mechanism and a reason why it's hard to deploy "virtual" hosts that live in multipe places on the network (e.g., for single-IP load balancing server farms, for virtual deployment of copies of a single IP in multiple places, etc.)
>
>
> and it's not required in IP that packets of a flow have to always take
> the same path to a destination.
>
>
>
> Path, no - agreed. But *destination*, yes. Again, the host *is* the destination.
>
>
>
> Without additional requirements on
> deployment, stateful devices break multi-path.
>
>
> Other way around; multipath breaks stateful devices (they don't work as desired) when they're not deployed *as the hosts they actually are and always have been* (at least when they perform certain functions we're talking about there).
>
>
>
> So if these devices need to *emulate* host behaviors then there really
> should be a specification to that effect.
>
>
> When you act as a host, you have to follow the rules of being a host.
>
>
>
> It's not enough to simply
> say they have to follow host requirements.
>
> They can't and they clearly
> impose additional requirements.
>
>
> I agree they don't; it's clear they CAN (it would be costly).
>
> They don't impose any new requirements beyond being the host they are, though.
>
Joe,

When they attempt to do host processing on packets that don't belong
to them they're not hosts. And when they do this, they impose a new
requirement that hosts do not have which is that packets for some flow
must consistently the traverse the same intermediate node.

In any case, as I said previously, reassembly is only specified as an
operations at destination hosts. It seems like there might be a need
for in-network reassmbly, or some nodes might be doing it already.
But, in that case we really need the specification of the protocol to
have a meaning discussion about it.

Tom

> Joe