Subject: [IPP] RFC: Link local addresses in URIs, addition for IPP Everywhere

From: Michael Sweet <[email-masked]>
Date: Thu, 10 May 2012 10:59:51 -0700

All,

Another issue that has come to light recently is the use of link-local addresses by printers that haven't gotten an IP address from a DHCP server.

To summarize the issue: RFC 3986 does not address how to represent link-local addresses in URIs.  Two separate (and incompatible) methods have been proposed for IPv6 addresses:

    http://tools.ietf.org/id/draft-fenner-literal-zone-02.txt       (expired)
    http://tools.ietf.org/html/draft-carpenter-6man-uri-zoneid-01

However, even if one of these methods is eventually adopted it is still impossible for a Printer to advertise the correct URI with a link-local address because zoneid strings are system-specific - they are basically the name of the network interface on the client.

What I'd like to do in IPP Everywhere is:

1. Add rationale of not using link-local numeric addresses in printer-uri-supported and other URI values: Link-local numeric addresses cannot be represented by the Printer because the zone identifier is specific to the Client and not the Printer.

2. Add normative requirement: Printers MUST NOT transfer/provide URI values using link-local addresses, SHOULD transfer/provide URIs values using the Host supplied in the Client HTTP request, SHOULD transfer/provide URI values using fully qualified domain names (FQDNs) in preference to numeric addresses, and SHOULD NOT transfer/provide URI values using numeric addresses obtained via DHCP or other auto-configuration protocols. Printers MAY advertise multiple printer-uri-supported values to cover all of the configured FQDNs and non-link-local numeric addresses.

3. Add implementation discussion where the printer can tailor the addresses reported to the Host: value supplied in the client HTTP request; printer-icons, printer-supply-info-uri, printer-more-info are not as flexible as printer-uri-supported, so using the value supplied in the Host HTTP request header is important.

4. Add security considerations text talking about DNS rebinding attacks - Printers SHOULD NOT allow requests with unknown or invalid Host values, including "localhost".

5. Add security considerations text referencing security consideration in current mDNS draft.

Thoughts?

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Thu, 10 May 2012 19:20:40 -0400

Hi Mike,

I concur w/ this I believe, certainly for IPv6 link-local addresses.

Does this also apply to ZeroConf IPv4 link-local addresses?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, May 10, 2012 at 1:59 PM, Michael Sweet <[email-masked]> wrote:

> All,
>
> Another issue that has come to light recently is the use of link-local
> addresses by printers that haven't gotten an IP address from a DHCP server.
>
> To summarize the issue: RFC 3986 does not address how to represent
> link-local addresses in URIs.  Two separate (and incompatible) methods have
> been proposed for IPv6 addresses:
>
> However, even if one of these methods is eventually adopted it is still
> impossible for a Printer to advertise the correct URI with a link-local
> address because zoneid strings are system-specific - they are basically the
> name of the network interface on the client.
>
> 1. Add rationale of not using link-local numeric addresses in
> printer-uri-supported and other URI values: Link-local numeric addresses
> cannot be represented by the Printer because the zone identifier is
> specific to the Client and not the Printer.
>
> 2. Add normative requirement: Printers MUST NOT transfer/provide URI
> values using link-local addresses, SHOULD transfer/provide URIs values
> using the Host supplied in the Client HTTP request, SHOULD transfer/provide
> URI values using fully qualified domain names (FQDNs) in preference to
> numeric addresses, and SHOULD NOT transfer/provide URI values using numeric
> addresses obtained via DHCP or other auto-configuration protocols. Printers
> MAY advertise multiple printer-uri-supported values to cover all of the
> configured FQDNs and non-link-local numeric addresses.
>
> 3. Add implementation discussion where the printer can tailor the
> addresses reported to the Host: value supplied in the client HTTP request;
> printer-icons, printer-supply-info-uri, printer-more-info are not as
> flexible as printer-uri-supported, so using the value supplied in the Host
> HTTP request header is important.
>
> 4. Add security considerations text talking about DNS rebinding attacks -
> Printers SHOULD NOT allow requests with unknown or invalid Host values,
> including "localhost".
>
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

---

From: Michael Sweet <[email-masked]>
Date: Thu, 10 May 2012 16:24:39 -0700

Ira,

> Does this also apply to ZeroConf IPv4 link-local addresses?

Yes, all link-local addresses have this issue, however the problem with IPv4 link-local addresses is typically mitigated by only having a single network interface bound to the link-local subnet (e.g. cross-over cable direct to printer) while IPv6 allows link-local on any subnet so clients can't make any assumptions if they have more than one network interface (pretty much the norm these days...)

---

From: Randy Turner <[email-masked]>
Date: Thu, 10 May 2012 20:48:02 -0700

Hi Mike,

Can you just simplify 1-3 below by saying implementations MUST NOT use literal link-local addresses in URI values?

Everything else is ok, right?

Randy

---

From: Mike Sweet <[email-masked]>
Date: Thu, 10 May 2012 21:58:42 -0700

Randy,

The main issue is link local, but when you start getting a mix of traditional and multicast host names being used (common for today's network printers) with a new reliance on the information supplied by the printer, it is really important that the client be able to use it... If the printer reports a .local name the the resource won't be accessible from outside the subnet. Similarly, if you get foo.example.com a client might not be able to resolve that if it doesn't have a proper dns server configured...

Sent from my iPad

---

From: Randy Turner <[email-masked]>
Date: Thu, 10 May 2012 22:22:57 -0700

Ok, so you're surfacing an issue that is pretty common in a client-server scenario:  a "service" should always advertise a contact point that is resolvable(name) and reachable(address) by any and all potential clients of the service.  Which, to your point, is an important concept.

Given the ubiquity of this requirement in client/server scenarios, there's probably language that we can borrow that describes this requirement.  OR we could keep it abstract, similar to the way I have described it above.

By the way, in your earlier #2 proposal, there was text that said "...SHOULD NOT transfer/provide URI values using numeric addresses obtained via DHCP or other auto-configuration protocols."

I don't think is correct -- we want to be able to use IPv6 literal addresses that are global in scope, or it would seem like we would want to -- and global-scope IPv6 addresses can be autoconfigured via DHCP or SLAAC.

Comments?

R.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 11 May 2012 08:31:20 -0700

Randy,

> Ok, so you're surfacing an issue that is pretty common in a client-server scenario:  a "service" should always advertise a contact point that is resolvable(name) and reachable(address) by any and a…

However, it is very common for printers to be reachable by multiple names and addresses. For example, "foo.example.com" may resolve to an external address for VPN users while "foo.local" resolves to an internal address for local users.  If you attempt to connect to "foo.example.com" from the internal network you'll typically get a "no route to host" error when you connect.

Also, domains are often used as different security domains (think Active Directory...) which have similar routing issues as well as any additional access control that might be involved.

My recommendation is simply there to address the resource lookups *after* discovery - most discovery protocols will give you a current address, port, and resource path for the IPP print service, but not for the supporting resources (localization file, icons, profiles, etc.) that can be queried.  And those resources don't have to be printer resident so a client can't make any assumptions about the values returned by the printer!

> ...

Yes we want to be able to use them, but both the IPP URI scheme and pending IPPS URI scheme recommend against it (per IETF policy) and DHCP addresses are almost always TEMPORARY.  You don't want to make a long-term binding to a numeric address, particularly in a mobile environment.

---

From: Randy Turner <[email-masked]>
Date: Fri, 11 May 2012 09:43:25 -0700

Hi Mike,

Good discussion.

The VPN-name vs. LAN-name situation is normally cleared up by 2-headed DNS, which most companies employ all the time -- that's not a problem we need to solve.  Like all service configurations, administratives have to "do the right thing" when they configure their servers.  "printer.foo.com" when resolved internally would map to the LAN IP, when "printer.foo.com" is resolved externally, it maps to some other IP that is exposed through the firewall.

I think my earlier statement regarding service "visibility" covers any possible client/server scenario, if we wanted to reuse that language in some fashion.

I agree with the recommendation about not using literal IP addresses in URIs,  especially with IPv6, since that's a bit messy.  That's probably a SHOULD NOT USE type of recommendation.

While it may be possible for a device to advertise multiple URIs for both the principal service, and other URIs (identifying different physical servers) for associated resources, I hope this is the exception and not the rule -- in fact, I would say we need a recommendation that says IPP Everywhere deployments SHOULD NOT use disseparate servers -- it makes the overall aggregate "uptime" for the service questionable, and creates potentially complicated policies for defaults if/when these associates resources are (for some reason) not available.

R.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 11 May 2012 10:25:07 -0700

On May 11, 2012, at 9:43 AM, Randy Turner wrote:

> 
> Hi Mike,
> 
> Good discussion.
> 
> The VPN-name vs. LAN-name situation is normally cleared up by 2-headed DNS, which most companies employ all the time -- that's not a problem we need to solve.

I agree that N-headed DNS works well for managed, mostly-static infrastructure. However, dynamic consumer services like dyndns and iCloud don't (and can't, as far as I can see) work that way.

For example, Apple has something called "Back to My Mac" that allows you to access your computers via iCloud, which handles setting up a secure tunnel between the two computers using your iCloud account. Part of this service is a DNS subdomain for your iCloud account, so I can access "imac27.NNNNNN.btmm.members.icloud.com" to get to my iMac at home. However, if I try to use that hostname when I am at home it won't work because the VPN address doesn't route from my home network.

Similarly, I have a DynDNS account setup that allows me to access that same iMac from non-Mac computers. The DynDNS hostname works great outside my home network, but does not work on the home network.

> While it may be possible for a device to advertise multiple URIs for both the principal service, and other URIs (identifying different physical servers) for associated resources, I hope this is the…

I suspect that consumer products will "obey" this limitation, but you can expect enterprise and "prosumer" products will continue to support (re)configuration of the printer to report externally-available resources. I say "continue to" because existing IPP-based printers already support this functionality.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Randy Turner <[email-masked]>
Date: Fri, 11 May 2012 10:47:12 -0700

Yes, I understand your consumer dynamic scenario…In the "old" days, admins would configure a service name (like "printer,apple.com") to return multiple IP addresses, and socket API recommendations say you're supposed to walk the list of returned addresses until you successfully connect to one.  So there would be a slight delay if you were home and wanted to access imac27.mike.members.icloud.com (unless the home IP address was the first address returned).

It gets even more complicated if your DNS setup is dual-stack in which case you're returning both A and AAAA records, in which case local resolver policy may force a delay if clients try to resolve IPv6 before IPv4 or vice-versa.

R.

---

From: Michael Sweet <[email-masked]>
Date: Mon, 14 May 2012 10:42:50 -0700

Randy,

> Yes, I understand your consumer dynamic scenario…In the "old" days, admins would configure a service name (like "printer,apple.com") to return multiple IP addresses, and socket API recommendations…

That's the issue - the DNS server supporting imac27.mike.members.icloud.com doesn't report what the *local* address is since it is usually in the private space (192.168. or 10.) which isn't something you want to publish (since it is likely you'd resolve and connect to that address but be talking to the wrong machine...)

We have specific ways of dealing with this for Bonjour-registered services - resolve the service instance name using mDNS (.local) first, then start a resolve on the BTMM domain 1 second later - so that we prefer local services over BTMM, but the same trick can't be safely used for hostnames in general and doesn't address things beyond the simple local/cloud naming issues.

> It gets even more complicated if your DNS setup is dual-stack in which case you're returning both A and AAAA records, in which case local resolver policy may force a delay if clients try to resolve…

IPv4/IPv6 is only one dimension. Even your traditional multiple-addresses-per-hostname configuration suffers from the "what address should I use" problem. Some implementations try one address at a time in the order they are returned, others try *all* of the addresses simultaneously (parallel threads) which is just nasty IMHO and breaks a lot of load balancers.

By having the Printer return the host and port that the Client provided we eliminate the guessing by the Client and allow it to do some simple caching (i.e. this is the address that works for "foo.example.com", at least until my network environment changes) so that things work well.

---

From: Randy Turner <[email-masked]>
Date: Mon, 14 May 2012 12:03:57 -0700

I mentioned "in the old days" because most clients I'm aware of, would try multiple addresses -- however, with the introduction of IPv6 and the fact that there will USUALLY be multiple IP addresses (CGA, link-local, tunnels, etc.).  Clients should be following the latest versions of the address-selection algorithms (both source and destination) discussed in RFCs 3484, 5221, and others.  These algorithms can be bypassed or otherwise affected by local policy files as well, which can complicate developer/operational assumptions.

Randy