Hi all, This discussion reminds me PMTUD against PLPMTUD - the same dilemma: It is always possible to ask help from different OSI layer. But asking help means: one are not capable to solve the problem by itself. I am more the sure that people from other OSI layer would be happy to help. IMHO: it is possible to keep "magic ping" discussion in the document, but it is better to concentrate on ND protocol as the primary vehicle for reachability resolution. Or else could be the question finally: do we really need ND? Eduard -----Original Message----- From: v6ops [mailto:v6ops-bounces@xxxxxxxx] On Behalf Of Pascal Thubert (pthubert) Sent: 16 сентября 2020 г. 13:13 To: Jen Linkova <furry13@xxxxxxxxx> Cc: iot-directorate@xxxxxxxx; v6ops@xxxxxxxx; iesg@xxxxxxxx; last-call@xxxxxxxx Subject: Re: [v6ops] Iotdir last call review of draft-ietf-v6ops-nd-cache-init-05 Hello Jen: We went a bit out of sync; please let me retry, and please read through before forming an answer to any specific point: There are basically 3 approaches. 1) The stack (not the app) triggers a single response from the outside of the subnet 2) GRAND 3) WiND (RFC 8505 + AP-ND) I believe we're already are good on 2) and 3). Obviously it pains me as an author that we are not doing 3 but as far as your spec is concerned, you have an argument and the reader can fetch RFC 8505 and form an opinion on the value that argument. The problem with 1) is that there is no spec to say what 1) is. So how can the reader validate your points on how bad it is? Linked to this is that major OSes have implemented their own version of 1). Not just phones. My Windows laptop reaches out to MSN to assess connectivity. My iphone reaches an Apple site and prompts the hotel signin page in case of a captive portal such as a hotel thingy. How Android does it you know better. Note to your points below (where we lost sync): this must be *completely transparent to the applications*. The idea in 1) would be that something like a tentative state where the address was formed in the stack but not available to the apps. There are a number of reasons for the stack to send a probe like this: prepare the NCE in the router as GRAND does, find a captive portal as my phone and PC do, assess the reachability from a ULA, check the MTU on the last mile... That OS magic is largely OS -specific, unspecified and undocumented. Which means that we cannot validate its value and effects, we cannot count on it, and, as opposed to WiND, we cannot refer to it to explain what it is we dismiss as a possible solution. Since there is no standard, GRAND is bound to explain what it is dismissing so the reader can decide to buy the argument of not. My very short description (reuse at will the below) of 1) would be that: - the stack gets an address (whichever way, autoconf, DHCPv6, assigned...) - immediately if it is ODAD, or else upon DAD time out, the stack sends a probe outside the subnet that generates an answer - you do not need to describe how that is done - The first return packet causes the router that serves the host to look up the address and form an NCE Note that in the text above the stack does not need to get the packet(s) back. All it cares is too get an NS from a router in a very short time. Such a description is enough for me. I can buy it is completely doable. Now we can look at pro cons: Pros: - no change in the router, works in legacy environment - something similar probably already exists in the stack for connectivity assessment - ... Cons: - still a reactive operation in the router, when GRAND creates a NCE in control plane (much preferable) - prepares the NCE in only one router, there might be more than one serving this device - may be subject to SAVI ingress filtering in case of ODAD since the address was not yet exposed to the network - delays the connectivity if the particular service that the stack reaches is offline though internet is available - real world routers may also drop the first packet. If the probe was useful beyond populating the cache, the host should retry it right after the NS/NA with the router. - ... Something in the line of the above would resolve my COMMENT. Now I can go to the details of your answer, but it mostly shows that we were out of sync: > > My birthday > > Bon anniversaire! Merci 😊 😊 😊 > > > > 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. This is an IPv6 discussion, not specific to a type of host. The hypothesis is that the generic IPv6 stack generates the packet autonomously before the address is usable by the applications. With ODAD that would be immediately. > Do you think we shouldn't care about those packets being lost and > allow the transport layer to deal with it? There cannot be since the socket is not yet available > > > - 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. Certainly not as you found out by now. Which affected systems are you talking about? I though that was the host that sends the probe. I'm saying that sending a NA or sending a packet affects the same host. The NA(non-O) to all routers also requires a change in the router so to that regard it looked harder to achieve > > > > - 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. If they generate more than one packet back. Otherwise there would be no problem would there? It seems that some phones poll multiple sites at the same time. A good thing to some regards but here's a side effect. Grand seems to be pushing the consequence of that decision to the router when essentially it is caused by that specific behavior of the stack, not the application. Note that I do agree that the overall result will be better if the stack keeps doing that and both the stack and the routers implement GRAND. This is why the pro cons above is so important. > > > > - 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'; That would be nice too; but for this spec I'm happy with the rough behaviour I detailed above > - change OSes so they all implement probing first and do not allow > applications to open a socket until the probing is completed? Yes. That can be done as part of ODAD. If you get a packet back, you know that the address was not a conflict in the router. > > It sounds to be like an overkill for the problem - the change is too > big (and implications are unclear). You may add that to the cons list : ) And we do standard to clarify implications. Which is why the BCP would be good. For now we leave it to the stack builder to do whatever they did. But the fact that they did it is the point. So, how is that different from the undocumented behavior of my phone and PC do today? They show 'no internet access' when the probe fails. > > > > 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? I think the section is useful. I was giving you a bit more arguments from the router's standpoint. I'd be happy that you give your version of those words in the final text. > > > > 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. I looked at it 😊 Not there yet. But we are converging I'm sure. > > > 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 takes lives on a different assumption that the application is involved. I believe this is beyond the landscape that we can safely consider. About " Detecting captive portals often require sending multiple packets." If we start with a TCP SYN and wait for a Syn-ACK, I do not see that. Could you elaborate in the cons section above? > > > > 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' Yes, sorry for being unclear > > > >> 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. I believe your draft is not limited to hosts that do slaac, but that the text above may be interpreted as so. I wish to clarify that GRAND applies in mixed and DHCP-only environments as well. Note that the host will talk to its DHCP server or Relay on-link and typically will use a link local address. In particular when SLAAC is not available it usually has no choice. See https://tools.ietf.org/html/rfc8415 section 5: " The client uses a link-local address or addresses determined through other mechanisms for transmitting and receiving DHCP messages. " > > > > 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 > ;) But then, this is human language. I'd rather be non-committal again and change: " most router implementations limit the buffer size to a few packets only, so all subsequent packets for the host global address are dropped, " To -> "routers happen to limit the amount of available buffers per address in which case some or all of the packets for the host global address may be dropped, " Note that in the real world, routers may also drop the first packet, in conscious disobedience to the RFC. Don't you observe that the first ping often fails? Worded as above, you do not give the impression that the first packet always comes back. Then again, the RFC did not take in consideration the effect of hardware-assist and the complication that ND requires in that case. Are we getting there ? Take care, Pascal _______________________________________________ v6ops mailing list v6ops@xxxxxxxx https://www.ietf.org/mailman/listinfo/v6ops -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
