Re: [nbs] NBS and TCP connection identification

[Rémi Després <[e-mail]>]

Hi Christian,

Sorry for so late an answer.
More below.

 
Le 29 sept. 2010 à 20:47, Christian Vogt a écrit :

> 
> Remi wrote:
> 
>> In my understanding NBS and address changes can remain independent, and therefore should remain so.
>> - A connection initiation starts with the source and destination names chosen by the initiator (and with valid addresses for them at that time).
>> The acceptor advertises at the NBS the names it received.
>> It may have before that checked, with a direct a DNS query, that source address and source name are consistent, or do it after signaling the incoming connection, or never, at its own choice. 
>> - Shim6, if present, works as before.
>> 
>> Does this make sense to you?
> 
> 
> I think it does.  So let me summarize:  
> 
> You are proposing that the responder should present the initiator's name as received to the responding application, without verification.  It is then up to the responding application to verify the initiator's name if needed.  Correct?

To be more precise, the proposal could be:
- For backward compatibility, the API permits the application to indicate whether or not it wants, for incoming connections, names at the API (by default, it doesn't).
- If it does, it also indicates whether it wants name-address consistencies, for sources and/or destinations, to be checked BEFORE or AFTER signaling the incoming connection at the API.
- For source names that are are provided in connection-initiating packets, direct DNS lookups are sufficient. Otherwise, reverse lookups are necessary.

RD


> Needless to say, if the initiator does not provide a name -- e.g., because it does not have a name registered in the DNS --, the responder would generate a name for the initiator based on the initiator's IP address.  Such a "synthesized" name does not have to be verified; it already provides the same level of security that we have today.

It isn't clear to me that synthesized names are needed. 
NBS APIs could instead continue to provide, in their binary format, addresses found in session originating packets, and let application ignore them if they aren't interested.


> 
> Is this summary accurate?
> 
> - Christian
>