Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-update

["Stuart W. Card" <[e-mail]>]

I think we are still often conflating _identifiers_ with _locators_ 
(addresses). I suggested looking at HHITs for 2 reasons:

- actually using them as such; and even if not

- seeing how HIP, HITs, HHITs clearly de-conflate ID vs location.

Any node ought to be able to have as many IDs as it likes, e.g., for 
different purposes, and as many addresses as it likes, and these ought 
to have _nothing to do with each other_, unless/until explicitly bound 
by some resolution process to support routing. Signature and asymmetric 
encryption should use keys bound to IDs (I am sure). Convergence layers 
ought to use addresses (I _think_).

On 10/15/2022 5:05 PM, [e-mail] wrote:
> Hi Mark,
> 
> On Fri, 14 Oct 2022, Rick Taylor wrote:
> 
>> Hi Scott,
>>
>> Comments inline...
>>
>> On 13/10/2022 22:06, [e-mail] wrote:
> 
>>>> Regarding HIT-based endpoint identifiers.  I personally think the idea
>>>> is very interesting - secure assertions of identity could be incredibly
>>>> useful in a DTN.  However, I don't think the 'ipn' scheme is the right
>>>> place for them, as there is too much fielded ipn code to make such a
>>>> major change.
>>>
>>> One could make the argument that any modifications to the existing
>>> 'ipn' scheme also have this effect on production deployments, and
>>> thus, these proposed changes are best put into a new scheme as well.
>>> Please elaborate on the difference in these two scenarion?
>>
>> I think the first scenario (using HHITs as the node-nbr) requires a
>> radical change to the assignment mechanisms, and a verification
>> mechanism to be added, altering the 'ipn' concept of "they're just
>> numbers" into something more complex.  The changes proposed in the draft
>> are meant to be as simple and unobtrusive as possible (but that is of
>> course subjective).
> 
> My concern here is that some existing implementations will require 
> non-trivial modifications to be compliant with the proposed changes, and 
> a range of circumstances may prevent these codebase modifications in a 
> timely basis. This is simply the "if it isn't broke, don't fix it" 
> paradigm.  Note that I am not opposed to the core ideas, but IMHO, they 
> should be implemented in a "small modular components" fashion, which, to 
> me, means implementing in a new scheme.
> 
>>
>>>
>>> On a different topic, can you please elaborate the the thoughts behind
>>> Section 4.1.5 of your draft?
>>
>> I hope I have covered the reasoning in Section 3.3?
> 
> One would think that if this would fall under a MUST situation, it would 
> have been explicitly specified in previous recomended standards.
> Basing fundamental changes on perceived implications can, in this case, 
> limit existing implementation functionality, developed based on existing 
> published specifications.
> 
>>
>>> It is both necessary and useful, when employing multiple different
>>> convergance layer adapters, to "multi-home" a particular node with
>>> different EIDs per convergance layer.  This is analagous to an
>>> internet host with multiple network interfaces.
>>
>> I think you are in danger of making a mistake with this line of
>> thinking.  An EID identifies an Endpoint - the logical name for some
>> service that either sends or receives bundles.  Although an argument
>> could be made that a particular implementation might want to name CLA's
>> using URIs for its own convenience, I strongly suggest that a CLA per-se
>> is not an Endpoint, and therefore has no EID.
> 
> Allow me to introduce myself.  I am Scott "Danger" Johnson :)
> Pardon my misapplied vernacular.  Let me restate in a more correct fashion:
> 
> It is both necessary and useful, when employing multiple different 
> convergance layer adapters, to "multi-home" a particular node with 
> multiple Node IDs, and, as a result, discrete EIDs per convergance 
> layer.  This is analagous to an internet host with multiple network 
> interfaces, discretely addresses on each interface.
> 
>>
>>> The proposed change would prevent simultaneous operation of IPv4 and
>>> IPv6 versions of CLAs within a node, as well as prevent simultaneous
>>> operation of UDPCLA TCPCLA and/or LTPCLA in some, if not all, existing
>>> implementations.
>>
>> I'm not aware of the internals of all existing implementations, but by
>> my reading of TCPCLv4 nothing in this draft prevents the correct
>> operation of multiple TCPCLv4 sessions via different IPv4/6 addresses
>> between nodes.
> 
> This is likely true if convergence layer adapters are implemented in a 
> dual stack fashion in a single daemon.  It becomes an issue when, for 
> operational efficiency purposes due to socket parsing and other 
> overhead, these are implemented in discrete daemons.  Further, the issue 
> reaches beyond only TCPCL on both IP versions.
> 
>>
>>> More to the point, it breaks existing deployments.
>>
>> Can you please elaborate, I do not believe it does, but I might have
>> missed something?
> 
> Below is an example ION runcontrol file and bpadmin duct listings.  
> Under your proposal, unless I am missing something, this operationally 
> functional configuration, implementing both LTPCLA over IPv4 and UDPCLA 
> over IPv6 would become immediately non-compliant:
> 
> ## begin ionadmin
> 1 20423921 ionconfig ''
> s
> a contact +1 [phone] 20423921 20423921 100000000
> a contact +1 [phone] 20423921 20423922 100000000
> a contact +1 [phone] 20423922 20423921 100000000
> a contact +1 [phone] 268435456 268435456 100000000
> a contact +1 [phone] 268435456 268435457 100000000
> a contact +1 [phone] 268435457 268435456 100000000
> a range +1 [phone] 20423921 20423921 1
> a range +1 [phone] 20423922 20423921 1
> a range +1 [phone] 20423921 20423922 1
> a range +1 [phone] 268435456 268435456 1
> a range +1 [phone] 268435457 268435456 1
> a range +1 [phone] 268435456 268435457 1
> m production 100000
> m consumption 100000
> ## end ionadmin
> ## begin ionsecadmin
> 1
> ## end ionsecadmin
> ## begin ltpadmin
> 1 64
> a span 20423922 32 32 1200 10000 1 'udplso 23.130.80.23:1113' 300
> a span 20423921 32 32 1200 10000 1 'udplso 204.239.2.1:1113' 300
> s 'udplsi 204.239.2.1:1113'
> ## end ltpadmin
> ## begin bpadmin
> 1
> a scheme ipn 'ipnfw' 'ipnadminep'
> a endpoint ipn:20423921.0 q
> a endpoint ipn:20423921.1 q
> a endpoint ipn:20423921.2 q
> a endpoint ipn:268435456.0 q
> a endpoint ipn:268435456.1 q
> a endpoint ipn:268435456.2 q
> 
> a protocol ltp 1200 100
> a induct ltp 20423921 ltpcli
> a outduct ltp 20423921 ltpclo
> a outduct ltp 20423922 ltpclo
> 
> a protocol udp 1400 100
> a induct udp 2602:fdf2:fab::1 udpcli6
> a outduct udp 2602:fdf2:fab::1 udpclo6 0
> a outduct udp 2602:fdf2:bee:feed::3 udpclo6 0
> s
> ## end bpadmin
> ## begin ipnadmin
> a plan 20423921 ltp/20423921
> a plan 20423922 ltp/20423922
> a plan 268435457 udp/2602:fdf2:bee:feed::3
> a plan 268435456 udp/2602:fdf2:fab::1
> 
> scott@spacelypackets:~$ bpadmin
> : l induct
> ltp/20423921    pid: 6116  cmd: ltpcli
> udp/2602:fdf2:fab::1    pid: 6117  cmd: udpcli6
> : l outduct
> ltp/20423921    pid: 6118  cmd: ltpclo max: 0
> ltp/20423922    pid: 6119  cmd: ltpclo max: 0
> udp/2602:fdf2:fab::1    pid: 6120  cmd: udpclo6 max: 65000
> udp/2602:fdf2:bee:feed::3    pid: 6121  cmd: udpclo6 max: 65000
> 
> If this remains compliant under your proposal, please accept my 
> retraction of objections raised.  If it becomes non-compliant, lets 
> continue to talk about it, as sending a bundle from an IPv6 only network 
> to be eventually delivered to an IPv4 only network would seem to require 
> a node with discrete ducts in one of the bops (bundle protocol hops) 
> along the path.
> 
> 
> 
> 
> Enjoy,
> Scott
> 
> 
>>
>>> In that light, there must be significant and reasonable justification
>>> for such a change, which would limit growth and deployment of
>>> terrestrial and perhaps potential functionality of space based networks.
>>
>> I agree.  I have tried to put forwards why I think each change is
>> necessary, but I am happy to hear counter-argument.
>>
>> Cheers,
>>
>> Rick
>>
>>
>>
>>>
>>> Looking forward to your response.
>>>
>>> Scott
>>>
>>>>
>>>> If you want to put forward a 'hit' URI scheme and suitable CBOR 
>>>> encoding
>>>> for BPv7, or something suitable already exists, I'd love to read it?
>>>>
>>>> Cheers,
>>>>
>>>> Rick
>>>>
>>>> On 09/10/2022 18:26, Robert Moskowitz wrote:
>>>>> Sorry I missed the call Wed; it was Jewish Holiday.
>>>>>
>>>>> Stu Card filled me in on some of the discussion around
>>>>> draft-taylor-dtn-ipn-update and HHITs as in:
>>>>>
>>>>> draft-ietf-drip-rid
>>>>>
>>>>> this is an advancement on the basic flatspace HIT in RFC 7401, and
>>>>> uses it for Identity and message Authentication.  It does not require
>>>>> the HIP protocol or ESP, but does not exclude their use.
>>>>>
>>>>> The point is that what currently exists for DTN identity, a 64-bit ID,
>>>>> fits well here with the HHIT prefix to provide the hierarchical
>>>>> structure.  Legacy DTN can be supported as rfc9063 does talk about
>>>>> non-cryptographic HITs (not recommended but...).
>>>>>
>>>>> An IPN Numbering Authority could map into the drip-rid RAA.  A
>>>>> specific IPN could be for non-cryptographic DTN ID with some HDA for
>>>>> system and some for services.  Probably also want to add a non-crypto
>>>>> ALG to specifically identify this in the prefix to not trigger the
>>>>> ORCHID part.
>>>>>
>>>>> But, moving forward, DTN could fully leverage trustworthy,
>>>>> non-spoofable, HHITs as DTN IDs.
>>>>>
>>>>> So after my Holidays (tonight starts Succos), I am interested in
>>>>> working with DTN in how HHITs can provide a much stronger Identity and
>>>>> how the non-internet connected evidence mode in drip-auth can work in
>>>>> DTN.  We had some evening discussions about this back in Philly.
>>>>>
>>>>> Note I just joined DTN list, so don't know what has been discussed and
>>>>> the sense of the wg.  And I am in the middle of my Holidays. But I
>>>>> wanted to chime in here and say that IMHO, HHITs is what you want.  :)
>>>>>
>>>>> Stu can provide more per some private messages we have had, and Rick
>>>>> can perhaps share some of those evening talk points.
>>>>>
>>>>> I will check back on Wed.
>>>>>
>>>>> Bob
>>>>>
>>>>> _______________________________________________
>>>>> dtn mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dtn
>>>>
>>>>
>>>> _______________________________________________
>>>> dtn mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dtn
>>
>>
>>
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn

-- 
Stuart W. Card, PhD: VP & Chief Scientist, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <[e-mail]> www.critical.com