Re: [MMUSIC] FQDN support in ice-sip-sdp

[Christer Holmberg <[e-mail]>]

Hi,

>>> But, the other reason was to correct issues and unspecified cases found in RFC 5245, and FQDN seems to be one such issue. 
>>> Unfortunately we didn't detect it before publishing RFC 8445, so any generic ICE FQDN procedures would have to be in a separate draft.
>>
>> Again, I don't have a strong opinion on whether the SDP specific parts of FQDN are in ice-sip-sdp or in a separate draft.
> 
> I think the question is if FQDN is just another way to encode a single IP address or if FQDN resolution affects ICE nomination process. 
> If we decide that demarcation point between ICE candidate signaling (ice-sip-sdp) and ICE nomination i(RFC 8445) s the list of candidates 
> with IP addresses, then handling FQDN falls under signaling (ice-sip-sdp). If you think DNS resolution affects ICE nomination process, then we will 
> need a separate draft for handling candidates with FQDN. I think former is the case and we can put FQDN handling in ice-sip-sdp.

Assuming the FQDN is split into separate candidates, and each candidate is processed just like any other candidate, I don't think the nomination process is affected. It also means that if I nominate the IPv6 "version" of a candidate, I am not allowed to switch to the IPv4 "version" - even if the connectivity checks have been successful. I am only allowed to use the transport associated with the nominated candidate.

>> Keep in mind that we also need to decide on whether ice-pac should be an ice-sip-sdp dependency, in which case the 
>> publication may get delayed anyway (eventhough we hope to finalize ice-pac pretty fast).
> 
> I do not think ice-sip-sdp needs to have ice-pac as dependency, but I am going to bring this up in another thread. 
>
> I wanted to concentrate on FQDN first and then address other ice-sip-sdp issues, such as the fact that SDP offer can contain an empty candidate list.

Yes. I did not want to discuss ice-pac in this thread, but simply point out that because of it we MAY have a dependency already.

>>> Figuring out how to handle multiple results per DNS query certainly warrants a separate draft and should be out of scope. 
>>
>> We also need to keep in mind that, even though a single DNS request only returns a single address, if some kind of load balancing is used 
>> different DNS requests may return a different address. Perhaps we need to cover that by saying that an ICE agent must not change the 
>> IP address:port associated with a candidate.
>
> This is part of the problem with DNS. One agent can publish FQDN that points to a single IP, but when another agent runs the DNS query, 
> it can return more then one result (such as DNS64), different result (some sort of NAT or proxy) or no results.. DNS network can be adversarial 
> and deliberately send traffic through a proxy for man-on-the-middle attack. I would prefer to limit what we require to each of the agents and 
> then allow connectivity checks to sort this out. So far the requirements are that agent that creates the candidate list should only use FQDN that 
> points to single address of given type and agent receiving the candidate list should only use candidate lines that produce a single address.

Yes.

>>> a. Define how to specify address type in candidate line. This is certainly an SDP problem and I think is a pre-requisite to using any addresses, such as 
>>> FQDN, where address type is non-obvious
>>
>> HOW to define the address type in a candidate lite is for sure an SDP problem. But, the fact that the address type needs to be 
>> provided for a candidate is an ICE problem. 
> 
> As I have mentioned earlier, this is the question of defining responsibilities of signaling vs actual ICE processing. DNS resolution does not have to be part of ICE processing and can be part of signaling. ICE processing can always start with the list of candidates with addresses already resolved.

Yes.

>> b. Specify that if agent compliant with ice-sip-sdp uses FQDN contact-address, it MUST specify addrtype for the candidate.
>
> Do we know how an existing implementation would process the addrtype? Are there any procedures regarding unsupported candidate properties?
>
> Since I just invented addrtype, I do not think anything would process it.

I was thinking about unsupported properties in general.

>>> Unsupported candidate properties are supposed to be ignored. We see a lot of unsupported properties in the wild, such as "generation" and "network-id". 
>>> These extra candidate attributes do not seem to cause any interop issues, so I do not think adding a new candidate type attribute would be a problem
>>>
>>> c. Specify that if FQDN resolves to a single address for the specified family then that this address is used for this candidate. Candidate lines with 
>>> FQDN returning multiple results per query MUST be ignored until their handling is defined in a future draft
>>>
>>> d. Specify what to do with FQDN without address type specified such as SDP from legacy RFC 5245 implementations. We can go with try AAAA resolution 
>>> first and use if single address is returned. If nothing is returned from AAAA query, try A query. If single address is returned, used that address, ignore 
>>> the candidate line otherwise. This matches RFC 5245 language and should work in all the same situations where RFC 5245 implementations were working.
>>
>> d) works assuming both ICE agents get the same IP address:port from DNS.
>
> Option d  is best effort for interop with current RFC 5245 implementations. It would work in the same cases when RFC 5245 implementation would. I am not sure any current RFC 5245 implementations actually use FQDN, but if such implementations do exist, this is what RFC 5245 specified.
>
>>> What do you think?
>>
>> I think you suggestion is good. But, as I have indicated, I would like to have a generic ICE FQDN draft that ice-sip-sdp (or a separate MMUSIC draft) references.
>>
>> Similarly to ice-pac, I think such draft could be produced relatively fast. It more or less only needs to say that:
>>
>> 1) An ICE agent that uses FQDN needs to provide one candidate per address family, and indicate the addrtype for each of those candidates.
>> 2) Some text regarding backward compatibility. Do we assume some default behavior by existing implementations, or do we require an ICE option?
>
> I do not think we need an ICE option. I think presence of addrtype can be sufficient.

But if the peer ICE agent does not support it, and the FQDN resolves into both IPv4 and IPv6, we don't know what version it will use.

> This being said we need to decide two things:
>
> 1. Does FQDN resolution belongs to ICE processing? In this case candidate list includes FQDN with address type and ICE processing describes how FQDN are resolved and converted to addresses. 
> Or, alternatively, does FQDN resolution belongs to ICE signaling? In this case candidate list includes resolved address and ICE agent deals with addresses only.

That would not work with mDNS, right?

> 2. Do we specify how to deal with FQDN in ice-sip-sdp or do we specify in ice-sip-sdp that FQDN must be ignored and their handling is defined in some other draft?

Perhaps the best thing would simply to produce a separate draft, to get some text. We can then decide whether to merge it into ice-sip-sdp.

Regards,

Christer