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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Sep 2020 14:01:49 +0000

Reviewer: Pascal Thubert
    Review result: Ready with comments
    Review Date: Sept 10th, 2020.

Dear Jen, 

I am assigned the IOT-DIR (https://trac.ietf.org/trac/int/wiki/IOTDirWiki) IETF LAST CALL review for draft-ietf-v6ops-nd-cache-init.
The review below is based on draft-ietf-v6ops-nd-cache-init-05. Please treat these comments just like any other last call comments.

I found the draft very readable and informative. In particular, the sections 3.x contain valuable information on why other possible variations of exchanges with the router (sending NS, RS, snooping, etc...) are less appropriate. Clearly I stay convinced that RFC 8505 is a better way for modern networks, but this proposal certainly helps - in the meantime.

Please find my comments below:

===========================================================================================================
Major
===========================================================================================================

Section 3 lists a number of approaches, but that list does not match the sections 3.x coming next.
In particular there is no section that explains why we are not " Making the probing logic on hosts more robust."
It seems that if the host sends just one probe to start with, the problem goes away. There must be a reason why this is not done today.

---------------------------------------------------------------------------------------------------------------------------------------------
"
Implementing such functionality is much more complicated than all
      other solutions as it would involve complex data-control planes
      interaction."

As it goes, reactive ND as it stands involve complex data-control planes interactions, the hardware needs to interrupt its process and tell the software in case of a cache miss.
This process is not only complicated but subject to DoS attacks and all prone to bugs. The solution eliminates that activity for a new address and that is a major plus for the router. Sadly it does not fix the problem permanently as the cache may be flushed. I believe it is important to mention both early in the draft to better position its value (great) and limits (the Neighbor cache is still a cache so the problem is not eliminated).

===========================================================================================================
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

---------------------------------------------------------------------------------------------------------------------------------------------

"
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.

---------------------------------------------------------------------------------------------------------------------------------------------

"
                             As in most cases the RA also contains the link-
       layer address of the router, the host can populate its Neighbor
       Cache with the router's link-local and link-layer addresses.
"
Maybe also clarify in before that sentence that the source IPv6 address of the RA is a link local address of the router (section 4.2 of RFC 4861)

---------------------------------------------------------------------------------------------------------------------------------------------

"
                                                                          Most router
       implementations buffer only one data packet while
"
Is that something you know for sure? Else, you may indicate instead that the standard only requires the router to hold one data packet.

For memory, RFC 4861 section 7.2.2.  "Sending Neighbor Solicitations" says:
"
...
   While waiting for address resolution to complete, the sender MUST,
   for each neighbor, retain a small queue of packets waiting for
   address resolution to complete.  The queue MUST hold at least one
   packet, and MAY contain more.  However, the number of queued packets
   per neighbor SHOULD be limited to some small value.  When a queue
   overflows, the new arrival SHOULD replace the oldest entry.  Once
   address resolution completes, the node transmits any queued packets.
...
"

---------------------------------------------------------------------------------------------------------------------------------------------

"If the host sends multiple probes in parallel"

See my Major comment above. With the description above it seems that the host is shooting itself in the foot doing this. 
Could you justify why the host needs to send multiple probes as opposed to wait for one to succeed?

---------------------------------------------------------------------------------------------------------------------------------------------

"connects to the network for the first time or after a timeout long"

Maybe "inactivity time" is more suitable than "timeout"

---------------------------------------------------------------------------------------------------------------------------------------------

" This option
   requires some investigation and discussions and seems to be excessive
   for the problem described in this document. "

The option itself is not "excessive", it is a technical solution. Maybe you could clarify what is excessive, e.g., the complexity to migrate, to implement and deploy, or the time till a solution is available commercially on all devices.

===========================================================================================================
Nits
===========================================================================================================

"if a host A has an neighbor": an -> a
"same sequence of events happen": happen -> happens

Voila!

Take care,

Pascal

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 11 Sep 2020 12:59:19 +0000

Thank you Pascal,

I am sure that the authors will use your detailed review to improve the document.

Regards

-éric

-----Original Message-----
From: Iot-directorate <[email-masked]> on behalf of "Pascal Thubert (pthubert)" <pthubert=[email-masked]>
Date: Thursday, 10 September 2020 at 16:02
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>
Subject: [Iot-directorate] Iotdir last call review of draft-ietf-v6ops-nd-cache-init-05

        Reviewer: Pascal Thubert

    Dear Jen, 

    "
    The

    "

    "
                                                                              Most router

    " This option

    Voila!

    Take care,

    Pascal

    -- 
    Iot-directorate mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/iot-directorate

---

From: Jen Linkova <[email-masked]>
Date: Tue, 15 Sep 2020 19:10:40 +1000

Hi Pascal,

Thanks a lot for your review and comments!
The IESG asked me to merge this draft and 6man-grand so only the
latter will be published.
However as most of the text from nd-cache-init has been moved to
6man-grand, your comments still apply - sorry, I missed your email and
did not address them in 6man-grand-02. The changes mentioned below
will appear in -03.

I've added the following text:
"

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.
- It's rather unlikely that all affected systems could be updated in
any reasonable timeframe.
- It would not solve the problem if there are multiple applications on
the same host sending traffic and return packets arrive
simultaneously.
- 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.

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."

Would it address your comment?

I've added a "Solution Limitations" section:

Solution Limitations

The solution described in this document provides some improvement for
a node configuring a new IPv6 address and start sending traffic from
it. However that approach does not completely eliminate the scenario
when a router receives some transit traffic for an address without the
corresponding Neighbor Cache entry. For example:

-- If the host starts using an already configured IPv6 address after a
long period of inactivity, the router might not have the NC entry for
that address anymore, as old/expired entries are deleted.
- Flashing the router Neighbor Cache would trigger the packet loss for
all actively used addresses removed from the cache.

Not necessary. Solicited RAs can be (should be) unicast.

> You could say "SLAAC and/or DHCPv6" for completeness.

Does RA contain information the host needs to perform DHCPv6? I'm not so sure..

> Maybe also clarify in before that sentence that the source IPv6 address of the RA is a link local address of the router (section 4.2 of RFC 4861)

Done:
"

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.
"

>    address resolution completes, the node transmits any queued packets.

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."

Done.

> The option itself is not "excessive", it is a technical solution. Maybe you could clarify what is excessive, e.g., the complexity to migrate, to implement and deploy, or the time till a solution is…

Changed to "This option requires some investigation and discussion.
However the implementation complexity and unclear adoption timeline
makes this approach less preferable than one proposed in this
document."

This text did not make it to 6man-grand anyway.

> Voila!

Merci! ;)

--
SY, Jen Linkova aka Furry

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 15 Sep 2020 10:52:52 +0000

Hello Jen

Many thanks for your detailed answer. Let’s see below :

Note that I added the IESG in cc since the merge was on their request.

> Le 15 sept. 2020 
My birthday 🎂😏

> will appear in -03

Better this way if you ask me on both a accounts. Merging looks good. And then we can isolate the review changes.

> work-around for one particular case of probing traffic. Packets are

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?

> 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 same host sending traffic and return packets arrive

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 ?

> 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.

> 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.

That is not a perfect response to the sweeping DOS attack though. You can only defeat it if the network has a full knowledge of all the addresses On Link and, e.g, the router plainly drops any cache miss in hardware. Sadly this draft doesn’t give us that, that’s the other point later below.

Also hardware assistance for the forwarding was just emerging and the related issues were disregarded. Implementing a reactive protocol with hardware assist is a great penalty to the router. The draft helps a lot as the situation can be mostly avoided. 

But the complicated code path cannot be removed for the same reason as above, we do not have a complete list. Less exercising may mean deteriorating, least exercised code paths being a familiar location for a bug nest.

All in all, this argument pleads for the full proactive solution more than the partial one (voluntarily avoiding quick and dirty because it is not the latter).

> Would it address your comment?

Not yet as you see. There are pros and cons.

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.

> all actively used addresses removed from the cache.

Flushing ?

> Not necessary. Solicited RAs can be (should be) unicast.

Sure, but then, using another address like link local 

> 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.

> Cache with the router's link-local and link-layer addresses.

-> is sent. Maybe avoid « in most cases » and uses « may » instead ?

> host global address are dropped, until the address resolution process

Not untrue. Does that mean true?

> makes this approach less preferable than one proposed in this

I’m good with that 

> This text did not make it to 6man-grand anyway.

De même (me too ;)

Pascal

---

From: Jen Linkova <[email-masked]>
Date: Wed, 16 Sep 2020 12:32:24 +1000

On Tue, Sep 15, 2020 at 8:52 PM Pascal Thubert (pthubert)
<[email-masked]> wrote:
> My birthday

Bon anniversaire!

> 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?

> 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.

> 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.

> 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).

> 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?

> 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.

> 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 fu…

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 ;)

> 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 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.

Done.

> Not untrue. Does that mean true?

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 16 Sep 2020 10:13:07 +0000

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.

> Bon anniversaire!

Merci 😊 😊 😊

> > 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

> > 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?
> 
> 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.

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.

> > > 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.
> 

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.

> > > 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.
> >
> 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.

> I've just submitted -03 which has the section about probing re-written.

I looked at it 😊

Not there yet. But we are converging I'm sure.

> > 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.
> 

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?

> 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

> 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.

"

> > > host global address are dropped, until the address resolution
> > > process is completed."
> 

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

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Sep 2020 12:28:52 +0200

> - immediately if it is ODAD, or else upon DAD time
> out, the stack sends a probe outside the subnet that generates an
> answer 

This has huge privacy and security implications.

On the other hand, if the host would do NUD using the new source address
and the router's (link-local) address then the host can be sure that the router
learned the host's new address. The host is then also sure that the
router considers the address on-link.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 16 Sep 2020 11:40:00 +0000

Hello Phil
 
> > - immediately if it is ODAD, or else upon DAD time out, the stack
> > sends a probe outside the subnet that generates an answer
> 

This is way, way too vague to be useful in the cons section. 
Can you please elaborate, like an example attack? 
Also, is the current stack behavior exposing the user to that threat as well?

> On the other hand, if the host would do NUD using the new source address and
> the router's (link-local) address then the host can be sure that the router
> learned the host's new address. The host is then also sure that the router
> considers the address on-link.

See https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-03#section-8.3

Keep safe, 

Pascal

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Sep 2020 14:50:22 +0200

> This is way, way too vague to be useful in the cons section.  Can
> you please elaborate, like an example attack? Also, is the current
> stack behavior exposing the user to that threat as well?

Suppose every device basics pings $vendor.com when it gets a new address as
part of a very low level function of the stack.

So basically we spend a lot of time worrying about tracking devices. We have
randomized MACs. We avoid embedding MAC addresses in IPv6 addresses and then
we have all devices advertise what their vendor is and their current addresses.

Anybody who wants to do monitoring will have a field day.

I know that mobile devices do some weird stuff, but not all devices are
mobile devices. And the whole captive portal discovery seems to be mostly a
flight between device vendors and captive portals. There is no technical
reason it has to be this ugly for mobile devices.

The situation would be better if there were a well-known anycast address.
However that has operational implications (pinging $vendor as well, because
it has happened often enough that vendors stopped renewing the DNS registrary
after they stopped supporting a particular brand of devices).

Even the well-known address may cause operational problems for disconnected
operation.

> See
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-03#section-8.3

Of the disadvantages:
- The first point can be solved by pinging the first hop router 
- The second point also applies to pinging an off-link destination
- There can always be broken middle boxes. I.e., if a wireless device does
  ND proxying then it is up to the network admin to make sure that the
  router has enough capacity to perfom ND. In any case, the existance of 
  weird middle boxes should not be a reason to start pinging off-link 
  destinations.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 16 Sep 2020 13:22:26 +0000

Hello Phil

> Le 16 sept. 2020 à 14:51, Philip Homburg <[email-masked]> a écrit :
> 
> 
>> 

Certainly this is not what my pc or my phone do. They reach a dell known address from the OS vendor. Still there is no IETF spec / blessing / study about that behavior.

> reason it has to be this ugly for mobile devices.

One reason is that we did not specify a better way. 

> Even the well-known address may cause operational problems for disconnected

This is listed as a cons already.

>  weird middle boxes should not be a reason to start pinging off-link 

Actually I was pondering pinging the newly formed global address from an already formed link local one, passing ping the packet to the router at L2...

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 16 Sep 2020 10:48:12 +0000

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:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 16 сентября 2020 г. 13:13
To: Jen Linkova <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] Iotdir last call review of draft-ietf-v6ops-nd-cache-init-05

Hello Jen:

Pros:

Cons:

Merci 😊 😊 😊

> > > better with initial packet loss. For example, only one probe can 
> > > be sent or probes retransmit intervals can be reduced. However,
> > >
> > > work-around for one particular case of probing traffic. Packets 
> > > are still being lost.
> >
> laptop or other system. It just starts sending traffic - multiple flows.

> > > - It's rather unlikely that all affected systems could be updated 
> > > in any reasonable timeframe.
> >

> 
> > > - It would not solve the problem if there are multiple 
> > > applications on the same host sending traffic and return packets 
> > > arrive simultaneously.
> >
> > Note that some phones send a crafted packet to detect, e.g., a hotel 
> > portal. Is
> that really different ?
> 

> 
> > > - Even if a host sends a single probe, the response might consist 
> > > of multiple packets and therefore might be still affected by the 

> 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.
> 

I looked at it 😊

> 
> > Sending a single probe provides a local solution with no dependency 
> > on the
> router.
> >
> 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.
> 

> > > Does RA contain information the host needs to perform DHCPv6? I'm 
> > > not so
> sure..
> client starts talking to the server using the global address, the problem goes away.

"

> 
> > > 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 
> > > 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."
> 

Are we getting there ?

Take care,

Pascal
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 15:19:51 -0400

Pascal Thubert \(pthubert\) <pthubert=[email-masked]> wrote:
    > 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...

If there is a captive portal, as indicated by RA and/or DHCP, then
communicating with it will do exactly the desired NCE actions.

My understanding is that iOS will start rotating MAC addresses *even on the
same network* every 12hours.
I have no idea what they will do with their L3 addresses. 
I imagine they get recycled...  but it would be interesting if they were
allowed to be kept for open sockets.

There is an assumption is that WPA-X will need to be invoked at that point,
and that will re-establish the identity of the phone to an upper layer, but
layer-2 snoops will not be able to track beyond that point.

(Maybe they won't bother on unenccrypted wifi, which is often used in
airports/hotels where captive portals are?)

At that point, the NCE will need to be updated again and any captive portal
will either have to be connected to the WPA auth-server (to get the updated
l2 address), or the phone will need to visit the captive portal again.

    > 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.

I understand your point.
It would be good to describe method (1) somewhere, if only because hosts will
continue to have to do this until the other methods are widely supported.

    > 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.

Do you propose that the host is actually looking to receive that NS?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 15:27:02 -0400

Philip Homburg <[email-masked]> wrote:
    >> This is way, way too vague to be useful in the cons section.  Can you
    >> please elaborate, like an example attack? Also, is the current stack
    >> behavior exposing the user to that threat as well?

    > Suppose every device basics pings $vendor.com when it gets a new
    > address as part of a very low level function of the stack.

    > So basically we spend a lot of time worrying about tracking devices. We
    > have randomized MACs. We avoid embedding MAC addresses in IPv6

I agree with your observation.
That's why we need to specify a standard way, such that it could be an
anycast that is implemented in as many places as possible, so that it does
not leak too far.

    > mobile devices. And the whole captive portal discovery seems to be
    > mostly a flight between device vendors and captive portals. There is no
    > technical reason it has to be this ugly for mobile devices.

The CAPPORT WG has produced some really good work.
HTTPS everywhere is rapidly killing the UX on most existing hijack-based
captive portals, and I think that once a few places have CAPPORT based ones,
the marketing/UX people will kill the rest of them.
Getting that anycast in place could be part of the new solution.

    > The situation would be better if there were a well-known anycast
    > address.  However that has operational implications (pinging $vendor as
    > well, because it has happened often enough that vendors stopped
    > renewing the DNS registrary after they stopped supporting a particular
    > brand of devices).

Anycast in DNS?
I was thinking about a well known L3 address, with some kind of AS119-like
support dealing with ISPs that haven't configured it locally.
If we need to give it a DNS name, then .arpa is the right place.

    > Even the well-known address may cause operational problems for
    > disconnected operation.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-