[IPP] proposed mods to IPP everywhere spec (per my action item)

[IPP] proposed mods to IPP everywhere spec (per my action item)

Randy Turner rturner at amalfisystems.com
Wed Apr 11 01:57:37 UTC 2012


Yeah, RFC 2845 pre-dates DNSSEC, and you can enable dns update (BIND 9) with 2845 mechanisms (TSIG), but it still requires administrative support (configuration), so it doesn't address my earlier point about administrative/site support.

2136 with 2845 would be easier to implement in clients than that described in my previous email, but there is a key management issue with 2845, including the fact that it uses an HMAC based on a deprecated hash function (MD5).

I think anything that requires admin support (wide-area bonjour or hierarchical DNS service) should probably be a "SHOULD".   I'm not sure sites that are moving to DNSSEC would enable an older form of security if they're going to the trouble of implementing DNSSEC.

As I mentioned before, we could add a section to our documents that talks about compliance and "site requirements", which would address anything "NOT" in the device.

Randy


On Apr 10, 2012, at 4:43 PM, Michael Sweet wrote:

> Randy,
> 
> See:
> 
> 	http://dns-sd.org/ServerSetup.html
> 
> 
> On Apr 10, 2012, at 2:30 PM, Randy Turner wrote:
> 
>> 
>> Hi Guys,
>> 
>> In theory, RFC 2136 would allow a client to update any RRset in a zone in DNS -- however, no one implements just RFC 2136 by itself, since the security implications would be enormous.
>> 
>> RFC 2136 would require a vendor to allocate a fair amount of development resources for implementation and testing.
>> 
>> In addition, early recommendations strongly suggested any implementation of RFC 2136 to also include an implementation of RFC 2137, which would require a bit more development and testing time.
>> 
>> However, RFC 2137 has been obsoleted through the introduction of DNSSEC mechanisms (RFC 4033, 4034, and 4035), which require a bit more development.  It would also require the site to move their DNS servers to use DNSSEC.
>> 
>> Even with these pre-conditions, I'm still trying to determine if DNS server policies would allow arbitrary RRset updates (other than A/AAAA RR types)
>> 
>> Of course, MDNS (DNS-SD, ZeroConf, etc.) only requires mechanisms on the client (as everyone probably knows), and many imaging devices already support this technology, so I don't see any problem (at least for now) with making a "MUST" for MDNS records that assist IPP everywhere.
>> 
>> For server-based DNS, I would recommend against making this a "MUST", because the implications on vendors and sites may be too high -- I recommend making this requirement a "SHOULD" or "MAY".
>> 
>> I'll follow up some suggested wording for section 4.2.2, taking into account the above information.
>> 
>> Randy
>> 
>> 
>> On Apr 9, 2012, at 1:00 PM, Randy Turner wrote:
>> 
>>> 
>>> Yes, I understand that DNS-SD allows "self-publication" and I'm fine with that.
>>> 
>>> I guess it's the DNS server case that still (I believe) requires administrative assistance.
>>> 
>>> R.
>>> 
>>> 
>>> On Apr 9, 2012, at 11:44 AM, Ira McDonald wrote:
>>> 
>>>> Hi Randy,
>>>> 
>>>> Printers already commonly publish themselves in SLP (if servers are
>>>> present) and LDAP/Active Directory automatically.
>>>> 
>>>> Adding the IPP Everywhere MDNS requirement for DNS-SD publish
>>>> of LOC and TXT records is a matter of parity in discovery protocols.
>>>> 
>>>> 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:blueroofmusic at gmail.com
>>>> Winter  579 Park Place  Saline, MI  48176  734-944-0094
>>>> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
>>>> 
>>>> 
>>>> 
>>>> On Mon, Apr 9, 2012 at 2:05 PM, Randy Turner <rturner at amalfisystems.com> wrote:
>>>> 
>>>> Hi Mike,
>>>> 
>>>> You're right about multicast DNS not requiring site administration, but dynamic DNS is only designed to update A/AAAA records in a zone.  I'm not aware of anyone using dynamic DNS to update TXT, SRV, or other resource records.  I haven't seen this done.
>>>> 
>>>> Randy
>>>> 
>>>> On Apr 9, 2012, at 10:59 AM, Michael Sweet wrote:
>>>> 
>>>> > Randy,
>>>> >
>>>> > Thanks for the text.  Comments below.
>>>> >
>>>> > On Apr 9, 2012, at 10:24 AM, Randy Turner wrote:
>>>> >>
>>>> >> Hi Guys,
>>>> >>
>>>> >> Proposed mods for wd-ippeve10-20120201:
>>>> >>
>>>> >> 4.2.2 Geo-Location (LOC)
>>>> >>
>>>> >> Site administrators MUST (should this be a "SHOULD" ?) publish LOC records (RFC 1876) to provide the physical location of a printer.
>>>> >>
>>>> >> 4.2.3 Service Information (TXT)
>>>> >> Site administrators MUST publish ("SHOULD" ?)….
>>>> >>
>>>> >>
>>>> >> This document is placing requirements on devices for future compliance with an IPP everywhere standard -- however, DNS requirements are NOT requirements placed on a device, but rather administrative requirements for the site DNS -- so I'm not sure that 4.2.2 and 4.2.3 belong in this document.
>>>> >
>>>> > Multicast DNS (part of Bonjour, and a perennial draft awaiting love from the IETF DNS WG) is not managed by site administrators and is part of IPP Everywhere.
>>>> >
>>>> > Also, printers *can* register their own DNS records with traditional DNS infrastructure using dynamic DNS updates (RFC 2136) and many already have support for this...
>>>> >
>>>> > Anyways, I am happy to note that these are requirements for Multicast DNS and recommendations for traditional DNS.
>>>> >
>>>> > ________________________________________________________________________
>>>> > 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
>>>> ipp at pwg.org
>>>> https://www.pwg.org/mailman/listinfo/ipp
>>>> 
>>> 
>>> 
>>> -- 
>>> This message has been scanned for viruses and 
>>> dangerous content by MailScanner, and is 
>>> believed to be clean.
>>> _______________________________________________
>>> ipp mailing list
>>> ipp at pwg.org
>>> https://www.pwg.org/mailman/listinfo/ipp
>> 
>> 
>> -- 
>> This message has been scanned for viruses and 
>> dangerous content by MailScanner, and is 
>> believed to be clean.
>> _______________________________________________
>> ipp mailing list
>> ipp at pwg.org
>> https://www.pwg.org/mailman/listinfo/ipp
> 
> ________________________________________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20120410/4ac5d69f/attachment-0001.html>


More information about the ipp mailing list