Re: [Deepspace] [dtn] technical remarks

On 26 Sep 2023, at 11:06, sburleig.sb@gmail.com wrote:

> First up:
>
>
>
> From: Marc Blanchet <marc.blanchet@viagenie.ca>
> Sent: Monday, September 25, 2023 8:54 PM
> To: Scott Burleigh <sburleig.sb@gmail.com>
> Cc: deepspace@ietf.org; DTN WG <dtn@ietf.org>
> Subject: Re: [dtn] technical remarks
>
>
>
> The “late binding” concept built into the BP suite is based on the idea that connectivity lapses between nodes on an end-to-end path may be so lengthy (hours certainly; days for some deep space missions) that the destination node may change its location – its IP address – while traffic is en route to its earlier address.  Will this simply not happen frequently enough to justify late binding measures?  If so, can you explain why?  If not, how will Internet architecture handle these anomalies?
>
>
>
> The fact that a node changes location does not mean changing its IP address.
>
>
>
> [SB]        The words “its location – its IP address –“ were intended to indicate that I meant, precisely, the node’s location in network topology, not its location in physical space.  That may not have been clear.
>
>
>
> QUIC has the IP address and/or port change managed securely. The peers confirm their new IP address/port change by a crypto change, since they already have established a trust relationship in the first handshake. So it is robust to DOS or man-in-the-middle attacks and it works with IP address/port change.
>
>
>
> [SB]        What works?  The destination address of the packet is different from the IP address at which the intended destination now resides.  How does the packet get routed to the destination node at its new address?
>
>
>
> Routing is not QUIC business. IP is responsible about it.
>
>
>
> In some ways, BP « does everything ». Here, QUIC does some, IP does other, HTTP does other. It is a layered approach, with responsabilities for each.
>
>
> [SB2]     But we’re not talking about BP, right?  We’re talking about IP in deep space.  I’m not asking about how QUIC resolves this problem, I’m asking about how the deepspace IP framework resolves this problem.  Do we have an answer?
>
> And how long does it take to make that happen?
>
>
>
> [SB2]     And an answer to this as well?
>
>
>
> A related point: will DNS be used across the solar system to resolve destination names to IP addresses?  If so, will DNS lookup queries traverse interplanetary links
>
>
>
> Should not.
>
>
>
> or will they be resolved by local DNS servers?
>
>
>
> yes.
>
>
>
> If the latter, will DNS information be synchronized across the solar system by zone transfers or something similar?
>
>
>
> The ones you need.
>
>
>
> [SB]        What do you mean?  Are you saying that the DNS changes will be synchronized across the solar system in exactly the same way that they are synchronized across the Internet on Earth?  If not, what will be done differently?
>
>
>
>   In either case, are we confident that the volume of DNS synchronization traffic across the interplanetary network will be so low as not to significantly degrade science traffic?
>
>
>
> As answered to Keith in another email, there is a draft on DNS deployment which is already written and currently reviewed by DNS experts. I’m awaiting a few more reviews and will publish. Up to now, no reviewer got heartburn.
>
>
> [SB]        So it is now known that the way in which DNS changes are propagated will work across the solar system without modification and any delays in that information propagation will have no impact on the performance of the network?
>
> Very respectfully, I suggest that we just wait for the draft on DNS to be published and continue that conversation there. The reason is that I will have to essentially pull out the whole draft into these email conversations.  I’ll let a few days pass to wait for incoming reviews and will publish anyway at the end of this week. Then I suggest we resume that conversation on DNS.
>
>
>
> [SB2]     Okay, but isn’t there a dissonance here?  If IP with QUIC and RESTful HTTP and RESTCONF will “just work” in deep space, without modification (just proper configuration and appropriately set timers), why is a new DNS draft needed?
>
>
>
> [SB2]     More to the point, though, my real concern is not DNS but rather those destination nodes whose IP addresses change during the hours or days while packets destined for those nodes are en route to their old addresses – the “late binding” concept.  Are we saying that this will not happen often enough to worry about?

Why are you saying that the IP addresses will change? IPv6 provides enough address space, that there is no need to change IP address from network operations point of view.

Dean

> -- 
> Deepspace mailing list
> Deepspace@ietf.org
> https://www.ietf.org/mailman/listinfo/deepspace