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

[Roman Shpount <[e-mail]>]

Hi  Christer,

On Sun, Apr 14, 2019 at 4:43 AM Christer Holmberg <
[e-mail]> wrote:

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

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.

> Please note, that if we specify that candidate line using FQDN
> contact-address MUST specify address type and FQDN MUST resolve
> > to a single address per address type, then FQDN handling is trivial:
> Agent should do a DNS resolution and use the result.
>
> Yes.
>
> > 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.

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

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

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.

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?

Based on answers to these questions we can deiced how many additional
drafts we will need.

Regards,
______________
Roman Shpount