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

[[e-mail]]

I agree that the ipn URI scheme is not the right place for HHITs in DTN, but I think defining a new HHIT-based URI scheme for BP EIDs could be excellent.

Scott

-----Original Message-----
From: dtn <[e-mail]> On Behalf Of Jorge Amodio
Sent: Sunday, October 16, 2022 6:39 PM
To: Stuart W. Card <[e-mail]>
Cc: [e-mail]; Rick Taylor <[e-mail]>; [e-mail]
Subject: Re: [dtn] Using HHITs for draft-taylor-dtn-ipn-update


Comments inline …

> On Oct 16, 2022, at 4:48 PM, Stuart W. Card <[e-mail]> wrote:
> 
> 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.

Just confessing my own ignorance, has HHIT been adopted as a standard even experimental ?
What are the use cases/applications?

I guess it can be used as an alternated scheme.

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

I believe there are no limitations at least on ION to have more than one ID as long as it is unique.

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

CLAs and LSAs should be able to use the address space of the convergence protocol, like LTP over UDP using IP addresses to define spans.

I don’t seed the need besides what ScottB is proposing and the clarification Brian Sipos provided in his draft, to get the ipn scheme more complicated than it is now.

My .00002
Jorge

> 
>> 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
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn

_______________________________________________
dtn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dtn