[ipv6hackers] SEND implementation Patent
Ahmad Sadeh
SEcure Neighbor Discovery (SEND) is a Standards Track which is defined in
RFC 3971.
It is a subject to patent US 2008/0307516 A1 (
http://www.freepatentsonline.com/y2008/0307516.html )
My question is how RFCs implementations become Patents while it is open for
all? What are the consequences of having patents for network protocols?
We implement SEND for Windows (WinSEND) (
http://www.hpi.uni-potsdam.de/meinel/forschung/security_engineering/ipv6_security/winsend.html).
Could we have a patent for "WinSEND" or even make it a product?
Thanks,
Ahmad AlSadeh
_______________________________________________
Ipv6hackers mailing list
Ipv6h...@lists.si6networks.com
http://lists.si6networks.com/listinfo/ipv6hackers
Richard Barnes
nothing enforceable unless it gets granted.
Even if it is granted, any claims related to SEND would seem to be
trivially invalid, given that the patent was filed in 2007, while RFC
3971 is dated 2005:
<http://tools.ietf.org/html/rfc3971>
There is also an IPR notification from Ericsson on RFC 3971, but they
assert that they will not enforce against implementors of the
standard.
I would say that there's nothing to worry about here.
--Richard
Fernando Gont
> SEcure Neighbor Discovery (SEND) is a Standards Track which is
> defined in RFC 3971. It is a subject to patent US 2008/0307516 A1 (
> http://www.freepatentsonline.com/y2008/0307516.html )
>
> My question is how RFCs implementations become Patents while it is
> open for all? What are the consequences of having patents for network
> protocols?
Probably the best way to think about IETF specs (in general) nowadays is
to consider them as "open" in the same sense the word open is used for
"open source" (which does not necessarily mean "free" as in freedom).
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Fernando Gont
> Even if it is granted, any claims related to SEND would seem to be
> trivially invalid, given that the patent was filed in 2007, while RFC
> 3971 is dated 2005:
> <http://tools.ietf.org/html/rfc3971>
>
> There is also an IPR notification from Ericsson on RFC 3971, but they
> assert that they will not enforce against implementors of the
> standard.
IIRC, there's another IPR by Microsoft regarding CGAs...
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
Richard Barnes
For the full list:
SEND: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3971
CGA: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3972
Ahmad Sadeh
Microsoft Research and one of authors for
RFC 3971 http://tools.ietf.org/html/rfc3971 (B. Zill ) from Microsoft.
But, why Microsoft does not implement SEND? as we can find
http://technet.microsoft.com/en-us/library/bb726956.aspx
"However, Microsoft does not support SEND in any version of Windows."
Ahmad
On Mon, Mar 12, 2012 at 11:08 PM, Richard Barnes
<richard...@gmail.com>wrote:
Fernando Gont
> RFC 3972: http://tools.ietf.org/html/rfc3972 is proposed by T. Aura,
> Microsoft Research and one of authors for
>
> RFC 3971 http://tools.ietf.org/html/rfc3971 (B. Zill ) from Microsoft.
>
> But, why Microsoft does not implement SEND? as we can find
> http://technet.microsoft.com/en-us/library/bb726956.aspx
Because with other unsecured pieces, such as the DNS, SEND does not
really make sense?
Also, because many other systems do not implement it, either, so it
doesn't pay much to be the first to do so?
Ahmad Sadeh
> On 03/13/2012 05:15 AM, Ahmad Sadeh wrote:
> > RFC 3972: http://tools.ietf.org/html/rfc3972 is proposed by T. Aura,
> > Microsoft Research and one of authors for
> >
> > RFC 3971 http://tools.ietf.org/html/rfc3971 (B. Zill ) from Microsoft.
> >
> > But, why Microsoft does not implement SEND? as we can find
> > http://technet.microsoft.com/en-us/library/bb726956.aspx
>
> Because with other unsecured pieces, such as the DNS, SEND does not
> really make sense?
>
SEND secures NDP messages. If it is not possible to secure the other
pieces, such as DNS with SEND, I think, it is more reasonable to find other
approaches to secure these "unsecure pieces" rather than leave the whole
"pieces" unsecure. Is it right?
>
> Also, because many other systems do not implement it, either, so it
> doesn't pay much to be the first to do so?
>
The "Standards Track" does not mean that it must be supported by the
systems that support IPv6? So why many systems do not implement SEND?
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fg...@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
Thanks,
Ahmad Alsadeh
Gert Doering
On Tue, Mar 13, 2012 at 10:28:58PM -0300, Fernando Gont wrote:
> Because with other unsecured pieces, such as the DNS, SEND does not
> really make sense?
>
> Also, because many other systems do not implement it, either, so it
> doesn't pay much to be the first to do so?
Well, since Microsoft likes people to live in a closed world anyway,
and has the most of the needed CA infrastructure already in-place in
their active directory environment, it would be fairly easy to add
SEND and "some sort of secure name resolution" to a Windows forest...
... and even good marketing: look, with Microsoft, your network is
much more secure than with Unix etc.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Richard Barnes
need to get hosts and routers issued certificates and key pairs.
Which you probably be straightforward with something like Active
Directory, but quite complex (especially w.r.t. the routers). So I
could definitely see someone like Microsoft deciding that it was
something that would be expensive in developer time to make
deployable, and not something that their customers are clamoring for,
thus a low priority.
Fernando Gont
> ... and even good marketing: look, with Microsoft, your network is
> much more secure than with Unix etc.
Oh, come on... you know that's not true ;-)
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
Douglas Otis
> On 03/13/2012 05:15 AM, Ahmad Sadeh wrote:
> > RFC 3972: http://tools.ietf.org/html/rfc3972 is proposed by T.
> > Aura, Microsoft Research and one of authors for
> >
> > RFC 3971 http://tools.ietf.org/html/rfc3971 (B. Zill ) from
> > Microsoft.
> >
> > But, why Microsoft does not implement SEND? as we can find
> > http://technet.microsoft.com/en-us/library/bb726956.aspx
>
> Because with other unsecured pieces, such as the DNS, SEND does not
> really make sense?
Dear Fernando,
Clearly enhanced security is needed and should be much cheaper as part
of the OS rather than specialized network equipment. For example, Apple
uses TSIG/mDNS/kerberos to support Back to My Mac. Perhaps adoption of
DANE/DNSSEC will enable CA alternatives making SeND more attractive.
> Also, because many other systems do not implement it, either, so it
> doesn't pay much to be the first to do so?
When typical corporate LANs contain compromised systems, additional
efforts independent of IPv6 is required. Although Intrasite Automatic
Tunnel Addressing Protocol (ISATAP) and Teredo provide IPv6 connectivity
between hosts separated by IPv4 infrastructure, this tends to degrade
security. Nevertheless, IPv6 can be leveraged to establish end-to-end
security as demonstrated by various schemes such as DirectAccess or
BTMM. Instead of using shared secrets or SSL certs, SeND can offer a
"standard" deployment vehicle.
The challenge for such deployment is to also have local methods able to
endure disruptions. IEEE 802.1X-based authentication at the link layer
or TSIG/mDNS/kerberos could be fall-backs. Having such services bundled
into a $49 corporate grade offering could represent beginnings of a sea
change.
Regards,
Douglas Otis
Julius Kriukas
> pieces, such as DNS with SEND, I think, it is more reasonable to find other
> approaches to secure these "unsecure pieces" rather than leave the whole
> "pieces" unsecure. Is it right?
The SEND itself may not secure DNS but CGAs may help to solve one
particular DNSSEC problem.
DNSSEC provides security for the recursive resolver issuing the
request to the authoritative name server. The unsecured part is from
the client to recursive resolver. Client either have to recursively
look-up the request itself or ultimately trust its configured
recursive resolver.
CGAs provide means to prove that the IP address really belongs to the
sender of the packet and also ensures that this IP address cannot be
used without stealing self generated private key from the IP address
owner.
If recursive resolver would use CGA IP address then all its clients
could verify that they are really talking to the IP address they think
they are talking. In other words CGA helps to protect from MITM
attack.
CGAs would not help if the attacker somehow changes default recursive
resolver address in the client system (for example by using rogue DHCP
server) but it can protect from MITM attacks when DNS server is
configured statically.
The main advantage of CGAs is that you do not have to have the
certificate or public key of the DNS server. The IP address of the DNS
server is already the fingerprints of its key. Therefore you do not
have to maintain CA. Also clients may not use CGAs as they do not
really need to authenticate itself to the DNS server.
This scheme can be extended to provide authentication to IPSEC if you
do not want to authenticate the server but just the IP address.
Correct me if I am wrong.
--
Julius Kriukas
Eric Vyncke (evyncke)
> Also, because many other systems do not implement it, either, so it doesn't
> pay much to be the first to do so?
Indeed, AFAIK Cisco and H3C are the only ones having implemented SeND but I still hope to have more support either natively by the OS or by user-space add-ons
-éric
sth...@nethelp.no
> > pay much to be the first to do so?
>
> Indeed, AFAIK Cisco and H3C are the only ones having implemented SeND but I still hope to have more support either natively by the OS or by user-space add-ons
Steinar Haug, Nethelp consulting, sth...@nethelp.no
Fernando Gont
> trivially invalid, given that the patent was filed in 2007, while RFC
> 3971 is dated 2005:
> <http://tools.ietf.org/html/rfc3971>
>
> There is also an IPR notification from Ericsson on RFC 3971, but they
> assert that they will not enforce against implementors of the
> standard.
>
> I would say that there's nothing to worry about here.
Unless you're a lawyer, I don't think it's really possible to make that
claim -- you know what they said about the assumptions...
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
Fernando Gont
>> Also, because many other systems do not implement it, either, so it
>> doesn't pay much to be the first to do so?
>
> When typical corporate LANs contain compromised systems, additional
> efforts independent of IPv6 is required. Although Intrasite Automatic
> Tunnel Addressing Protocol (ISATAP) and Teredo provide IPv6 connectivity
> between hosts separated by IPv4 infrastructure, this tends to degrade
> security. Nevertheless, IPv6 can be leveraged to establish end-to-end
> security as demonstrated by various schemes such as DirectAccess or
> BTMM. Instead of using shared secrets or SSL certs, SeND can offer a
> "standard" deployment vehicle.
At the end of the day, the problem users usually have have little (if
anything) to do with lack of authentication at the network layer (which
is what SEND provides).
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________