Martin, I want to check one aspect of your response about MTU handling.
The entity which is originating the packets, and receiving the ICMP
responses, is the ITR. In most cases, the ITR is a router. I do not
know of any tunnel protocol for rotuers that expects the routers to
store state about the packets it has sent in the tunnels.
As these are low-state tunnels, and as the packets are those provided by
the sources behind the ITR, I doubt that we can use PLPMTUD, although I
would be happy to be given enough information to find I am wrong about that.
I am somewhat confused as to what you would have us do.
Yours,
Joel
On 8/6/2020 4:35 PM, Martin Duke wrote:
Hi Albert,
thanks for the edits, and sorry for the delay! We're not quite there on
a few of the items:
Though first, there is now a duplicate paragraph in Section 7. Please
delete one.
On Fri, Jul 31, 2020 at 5:43 AM Albert Cabellos
<[email protected] <mailto:[email protected]>> wrote:
On Fri, Jul 3, 2020 at 9:07 PM Martin Duke via Datatracker
<[email protected] <mailto:[email protected]>> wrote:
>
> Sec 5.3 What is in the Nonce/Map-Version field if both the N and
V bits are
> zero?
>
There is no field then.
so the bits are set to zero, or is the LISP header actually shorter by 3
octets?
>
> Sec 7.2 The stateful MTU design does not incorporate any security
measures
> against ICMP spoofing. At the very least, the ITR needs to make
sure that some
> fields in the outer IP and UDP headers are hard to guess, and
that this
> information is stored to verify that the ICMP message came from
on-path. If
> this is not possible, the design is not safe to use over IPv4. If
> hard-to-guess information is not available to be stored deeper in
the packet,
> then it is not safe over IPv6 either.
>
The source UDP port is random. We have therefore added the following
statement at the beginning of section 7.7:
An ITR stateful solution to handle MTU issues is described
as follows, this solution can only be used with
IPv4-encapsulated packets:
This is backwards, and anyway inadequate.
An off-path attacker can generate a fairly small number of ICMP messages
to reduce the MTU to ridiculously low levels (e.g. 68 bytes), which
depending on tunneling overhead could render the path unusable. The
defense against this is to either ignore ICMP messages (instead using
PLPMTUD
<https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/> to
find the MTU) or to compare the echoed information the ICMP message
against the stored contents of the packet, where obviously there needs
to be enough entropy to make it hard to guess. Generally the port is not
sufficient entropy, since it takes fewer than 2^16 packets to take you
down, but admittedly there isn't much UDP-based protocols can do about this.
In IPv6, the router should include as much of the packet as possible in
the ICMP packet, so the chance of guessing is low. It's therefore it's
simply a matter of specifying that hosts should store the packet payload
and do the validation step.
In IPv4, the router is required to include the first 8 bytes of the IP
payload (eg the UDP header), so all you have are the IP and UDP headers.
Hosts should still do the validation.
The main thing is to tell them to do that validation.
>
> Sec 7.2 There is a fourth situation which can arise. If the ETR
receives an
> ICMP packet from an EID in its network. I have a couple of
questions about what
> should happen in this case:
>
In this case the EID is locally attached to the xTR. Therefore, the
xTR has a locally configured MTU to reach the EID. So what is
written in the section already covers this scenario.
>
> - How is this communicated to the sender of the flow that
triggered the
> message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to
the source
> EID, both, or neither?
>
> - Is the ETR responsible for enforcing the MTU to that EID for
subsequent flows?
>
I read 7.2 again and I don't see that it does. According to this
section, what does the ETR do when it receives a packet from the ITR
that exceeds the locally configured MTU?
Martin
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
