Re: [v6ops] Iotdir last call review of draft-ietf-v6ops-nd-cache-init-05

[Jen Linkova <[e-mail]>]

On Tue, Sep 15, 2020 at 8:52 PM Pascal Thubert (pthubert)
<[e-mail]> wrote:
> > Le 15 sept. 2020
> My birthday

Bon anniversaire!

> > 8.7. Making the Probing Logic on Hosts More Robust
> >
> > Theoretically the probing logic on hosts might be modified to deal
> > better with initial packet loss. For example, only one probe can be
> > sent or probes retransmit intervals can be reduced. However,
> >
> > - This approach does not fix the root cause but just provides a
> > work-around for one particular case of probing traffic. Packets are
> > still being lost.
>
> If no one knows your address but the guy who replies I’m not sure of this. Maybe this item could be merged with your last point?

Let's say the host does not do probing - it's not a phone, it's a
laptop or other system. It just starts sending traffic - multiple
flows.
Do you think we shouldn't  care about those packets being lost and
allow the transport layer to deal with it?

> > - It's rather unlikely that all affected systems could be updated in
> > any reasonable timeframe.
>
> Not sure if I get you there. Isn’t it the same for getting this spec implemented ? If so maybe we can omit this argument. Or did you mean something else?

The proposed changes are done on the router/host OSes. What you are
suggesting might require updating *applications* if they are doing
probing.

> > - It would not solve the problem if there are multiple applications on
> > the same host sending traffic and return packets arrive
> > simultaneously.
>
> True. It would have to be done in the OS when forming the address and before any application can open a socket.
> Note that some phones send a crafted packet to detect, e.g., a hotel portal. Is that really different ?

It's exactly when the problem manifests very clearly.

> > - Even if a host sends a single probe, the response might consist of
> > multiple packets and therefore might be still affected by the problem
> > described in this document.
>
> I guess it takes a special crafting to make sure we get only one packet in response, e.g. a TCP SYN. But then that locks ressources on the other end.
>
> A variation of a ping over udp looks more suited. Or forming a security association with the DNS server? Hard to live with no DNS anyway.

So what you are proposing is:
- to publish a BCP for 'how to do probing';
- change OSes so they all implement probing first and do not allow
applications to open a socket until the probing is completed?

It sounds to be like an overkill for the problem - the change is too
big (and implications are unclear).

> > 8.8. Increasing the Buffer Size on Routers
> >
> > Increasing the buffer size and buffering more packets would exacerbate
> > issues described in [RFC6583] and make the router more vulnerable to
> > ND-based denial of service attacks."
> >
>
> Considering the vast address space that can be attacked there is no amount of memory that will fully protect against a sweeping DOS attack.
>
> The memory in a router is not constrained as it was 20 + years ago. We can allocate many times what we could at the time of the writing of classic ND. The attack can also be many times faster but then that makes the anomaly more recognizable and the router can raise defenses.
>
> I suppose that a platform that is worth attacking can throttle incoming requests.

It's what RFC6583 discusses.
So I'm not sure - are you suggesting to remove that section? or do you
think that we just need to increase the buffer size?

> > Would it address your comment?
> >
>
> Not yet as you see. There are pros and cons.

I've just submitted -03 which has the section about probing re-written.
I hope it's better now.

> Sending a single probe provides a local solution with no dependency on the router.
>
> I believe that the NA is a good thing, better than current state of affairs.
>
> Ideally the draft would describe both and provide recommendations on how to do the single packet as a step 0. Then it would do what it does today as step 1. Then it would open in conclusion to a future with a full proactive solution where the DOS attack is not possible any more.

See the updated section 8.7 - a single probe packet is not a solution.
So it leaves us with what the draft proposes.
https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-03#section-8.7

The full proactive solution is a completely different story, IMHO -
I'm not saying we shouldn't go that way but 'a few packets being lost'
is not a reason good enough to implement such drastic changes. So I'd
prefer to decouple 6man-grand and any proactive/registration-based ND
work.

> Flushing ?

Yeah. fixed ;)

> >> ===========================================================================================================
> >> Minor
> >> ==========================================================================================================="
> >>   1.  A host joins the network and receives a Router Advertisement (RA)
> >>       packet from the first-hop router (either a periodic unsolicited
> >>       RA or a response to a Router Solicitation sent by the host).
> >> "
> >> Maybe clarify that this is a multicast RA sent to all hosts
> >
> > Not necessary. Solicited RAs can be (should be) unicast.
> >
>
> Sure, but then, using another address like link local

Ah, I see what you are trying to clarify. Changed to 'The RA is send
from the router's link-local address to link-local destination'

> >> The
> >>       RA contains information the host needs to perform Stateless
> >>       Address Autoconfiguration ([RFC4862]) and to configure its
> >>       network stack.
> >> "
> >> You could say "SLAAC and/or DHCPv6" for completeness.
> >
> > Does RA contain information the host needs to perform DHCPv6? I'm not so sure..
> The M and/or O bits ... DHCP goes a very long way to configure the stack.

I'm just not sure DHCPv6 is relevant here at all. As soon as the
client starts talking to the server using the global address, the
problem goes away.

> > The RA contains information the host needs to perform SLAAC and to
> > configure its network stack. The RA is send from the router's
> > link-local address and in most cases also contains the link-layer
> > address of the router. As a result the host can populate its Neighbor
> > Cache with the router's link-local and link-layer addresses.
> > "
> -> is sent. Maybe avoid « in most cases » and uses « may » instead ?

Done.

> > Changed to:
> > "As per Section 7.2.2 of [RFC4861] Routers MUST buffer at least one
> > data packet and MAY buffer more, while resolving the packet
> > destination address. However most router implementations limit the
> > buffer size to a few packets only, so all subsequent packets for the
> > host global address are dropped, until the address resolution process
> > is completed."
>
> Not untrue. Does that mean true?

I'm under impression that binary logic is a foundation of electronics ;)

--
SY, Jen Linkova aka Furry