Identifiers in the data stream [Re: Default security functions on an IPv6 CPE]

[Brian E Carpenter]

On 2011-06-04 01:27, S.P.Zeidler wrote:
> Thus wrote Brian E Carpenter (brian.e.carpenter at gmail.com):
> 
>> On 2011-06-03 05:39, Steinar H. Gunderson wrote:
>>> [...] For sure, BitTorrent, Skype, and lots of different
>>> gaming protocols do this, and are in wide use. After all, how else
>>> would you initiate peer-to-peer communication?
>> Yes. This is a major wart on the Internet and will get significantly worse
>> now that we are deploying a second address family (therefore, it's almost an
>> ipv6-ops issue).
> 
> Correct me if I'm wrong, but isn't that being done to cope with NAPT, and
> could be ceased if the address that arrived at the referral server was an
> address that a peer could talk to? I.e. it would be no longer needed in a
> IPv6 world?

In a pure IPv6 world with no firewalls, no intranets, and no NPTv6, perhaps.
But I gave up hoping for that some years ago, and in any case we have to
live for ten or twenty years with v4/v6 coexistence.

If you want to continue the discussion, we have a list with a strange name
at https://www.ietf.org/mailman/listinfo/grobj

   Brian

> 
> Of course an answer to "tell me my peers" still would contain addresses
> (or FQDNs), but a host would no longer need to convey its own address(es).
> 
>> Over in another universe, there's
>> http://tools.ietf.org/html/draft-carpenter-referral-ps
>> but it has proved very hard to persuade the IETF that this
>> is a serious problem.
> 
> s/thrid-party/third-party/
> s/disciver/discover/
> 
> Interface selection would need auth or it becomes a man-in-the-middle
> attackers dream. I'd assume that the referral itself was adequately
> authenticated anyway.
> 
> Adding too many dimensions of preference to connectivity information will
> likely make the result too complicated and too often wrong (who, eg, will
> enter cost? how does a program know if a connection is metered or flat
> fee?). A simple preference policy is more likely to be correct.
> 
> I agree that using a FQDN is a less reliable solution for most clients,
> ie not-public-servers. Referral-by-DNS OTOH also happens (see eg MX),
> generally to public servers.
> 
> Are there situations in a net that only has 1:1 mappings where addresses
> that both made it to one referral server couldn't talk to each other?
> (Firewalls and games in the DFZ excluded).
> If not, it would seem easiest to let the reference be something simple
> that works, and afterwards let the partners of the communication
> handshake on optimizations, I'd say.
> 
> regards,
> 	spz