Subject: 6MAN Adoption call on draft-rafiee-6man-ssas-07

From: Ole Troan <[email-masked]>
Date: Tue, 19 Nov 2013 11:01:07 +0100

All,

We reconsidered the action from Vancouver, and decided to have the discussion on this draft as part of the adoption call instead.
Please provide a view with reasons as to whether the WG should adopt this or not.

This message starts a one week 6MAN Working Group call on adopting:

	Title           : A Simple Secure Addressing Scheme for IPv6 AutoConfiguration (SSAS)
	Author(s)    : H. Rafiee, C. Meinel
	Filename    : draft-rafiee-6man-ssas-07
	Pages        : 15
	Date          : 2013-11-4

    http://tools.ietf.org/html/draft-rafiee-6man-ssas-07

The call ends on November 26th, 2013.

Regards,

Bob Hinden & Ole Trøan

---

From: Ray Hunter <[email-masked]>
Date: Tue, 19 Nov 2013 11:58:10 +0100

> The call ends on November 26th, 2013.

I have read the draft and I'm sceptical.

I think the security considerations should at least address the
following elements.

The protocol to boot network connectivity (learn neighbours) is
dependent on correct time synchronisation between all nodes on the link.
Time synchronisation may itself be dependent on network connectivity,
creating a circular dependency. An attack on the time protocol could
potentially deny service to all nodes.

The protocol to boot network connectivity (learn neighbours) is
dependent on all nodes obtaining the public key of the neighbor. The
draft does not address how a node that is first joining the network can
bootstrap RPKI or how the public key is distributed.

The protocol to boot network connectivity (create a tentative address)
is dependent on trusting RA. Any attack on RA would be an attack on the
protocol.

Compute intensity of CGA was "by design." Any reduction in compute
intensity should be regarded with suspicion.

Replay attacks can occur very quickly. A time window of a "short period
of time" could be an eternity on a LAN.

DoS attacks could still overwhelm any node. It's a lot easier to send
junk than to check a signature, even with the reduced
receiving-algorithm complexity proposed in SSAS verification.

Equally an attacker could send unlimited "correct" neighbour
registration packets (up to 2^64) from a single node that pass all the
way to step 9 of the verification process, leading to resource depletion
of the neighbour cache or key cache on all nodes on the LAN.

Or the attacker could spoof the sending node's MAC address and create
collisions for every single packet on demand, or confuse the bridge CAM
table.

I'm personally of the opinion that if an attacker has full access to the
L2 link then all bets are off. If you're worried about such attacks then
there are existing technologies to address this e.g. point to point
links in wireless, private VLANs, or limiting the number of IPv6
prefixes and addresses per port in the switch hardware.

-- 
Regards,
RayH

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Nov 2013 10:50:39 -0800

Dan,

Thanks for your review comments.

If MLD-snooping was implemented in every L2 device (not just switches, 
but also wireless access points, etc) then the impact of multicast NSs 
sent for the purposes of address resolution would be reduced.

But the draft is also addressing the other cases of multicast:
  - periodic RAs
  - multicast NS/NA for the purposes of duplicate address detection
  - a host sending a multicast NS to its peer when the routers already 
know the MAC address of the peer; redirect messages solve that without 
any multicasts

All of those current uses of multicast are part of the motivation for 
the draft. The other part of the motivation is to facilitate sleeping 
hosts. If you follow the letter in RFC 4861/62 hosts have to be always 
be awake to respond to any DAD probe that might arrive, or the hosts 
have to redo multicast DAD each time they wake up. Finally having 
registrations in the routers provides a standardized approach of 
avoiding ND DoS attacks.

More comments below.

On 11/19/13 5:50 AM, Dan Luedtke wrote:> Hi,
 >
 > I know I am too late to make any significat contribution but I like to
 > express why I think this draft is only the second best solution to the
 > problem.
 >
 > A switch should not send a solicited node multicast packet to all
 > connected devices but only to those which's hardware address matches
 > the last 24 bit. In case of non-EUI64 addresses (e.g. Privacy
 > Extensions), the node has previously joined the solicited node
 > multicast groups matching the last 24 bit of its addresses. A switch
 > should track the corresponding MLD messages and thus be able to
 > transmit the multicast message only to the affected ports. Not every
 > multicast message on network layer has to become a broadcast message
 > on link layer. In fact, most switches just flood out multicast packets
 > on all ports, but I see more of a switch issue here than a protocol
 > flaw in NDP.
 > IMHO this is a problem on the link layer and should not lead to quirks
 > or increase of complexity in network layer protocols.
 >
 > On wireless links the situation is probably very different and the
 > wakeup of nodes heavily depends on how many multicast addresses the
 > hardware can listen to without waking up CPU and driver software. My
 > understanding is that there is some kind of hardware filtering before
 > the OS stack gets notified.

A fair number of existing Ethernets are being turned into wireless by 
adding wireless APs. Thus it would seem beneficial to have a common 
approach to reducing multicasts and facilitating sleeping hosts.

 > I also dislike the idea of centralizing the network management by
 > using a single instance (the router) for node registration. It's
 > probably more a personal thing but to me a network seems more reliable
 > if the nodes "defend" their addresses themselves via DAD.

As long as there is no packet loss and all the hosts are always awake 
and reachable, then the current RFC 4862 DAD is perfect. However, to 
make the current peer-to-peer DAD robust in the case of packet loss 
would mean multicast more than one initial DAD; periodic DAD packets 
would seem needed.

Note that it wouldn't be a single router but the set of routers attached 
to the link. We have an outstanding question around VRRP routers - and 
resolving that one should improve the distribution of the state across 
the routers attached to the link.

 > Here are my comments:
 >
 > Section 1.2:
 >> EUI-64 identifiers are recommended as unique Interface Identifiers,
 >> however if the network is isolated from the Internet, uniqueness of
 >> the identifiers may be obtained by other mechanisms such as a random
 >> number generator with lowest collision rate.
 > Does this collide with 
draft-gont-6man-deprecate-eui64-based-addresses-00?

Perhaps the draft needs to be more clear on this, but the use of the 
EUI-64 (or some other long-term stable identifier) in the ARO is solely 
local between the host and the 1st hop routers. (It is needed to tell 
the difference between a re-registration by the same host and a 
conflicting registration by some other host.)

That is orthogonal to any use of EUI-64 in IPv6 IIDs and IPv6 addresses 
- they do not need to use EUI-64 to use ARO. Hence we can (and IMHO 
should) deprecate the EUI-64-based addresses.

But we clearly need to state this in the document - it isn't the first 
time the question has come up.

 > Section 3.:
 >> An EUI-64 interface ID required for global
 >> communication.
 > See above.
 >
 > Section 9:
 >> A legacy IPv6 Host compliant EAH SHOULD be able to fall
 >> back to RFC 4861 host behavior if there is no efficiency-aware router
 >> (NEAR) in the link.
 > I would like to see a MUST here instead of a SHOULD. The definition of
 > "legacy compliant" implies being able to fall back. Did I miss the
 > point here?

Perhaps the "legacy compliant" is unfortunate. If we remove those words 
I think a "SHOULD" is the proper choice - perhaps with an additional 
explanation that such fallback is needed in order to interoperate with 
legacy routers. So we'll reword it.

 > Section 10.2:
 >> The new default
 >> router then first sends a NS to its peers with a link scope multicast
 >> message to IPv6 address ff02::2 with the ARO option.
 > Just bikeshedding, sorry, but I would like to see "all link-local
 > routers multicast address" instead of the constant ff02::2.

Thanks - will fix.

 > Section 20:
 >> MIN_DELAY_BETWEEN_RAS(CHANGED)          1 second
 > Wow. I consider this a big change! What is the reason for chosing 1
 > second? We are not speaking of periodic RA, right? Then why wait a
 > second between two unicast RA, it does slow down things. For example
 > massive movement of mobile clients from one wifi to another. Happens
 > on conferences sometimes :)
 > Again, I might miss the point here since I had not the time to get to
 > know this draft earlier.

MIN_DELAY_BETWEEN_RAS is only for multicast RAs (see RFC 4861).
Perhaps we should clarify this in the document.

 >
 > Some possible minor typos?!:
 >> intermediate devices include Wireless Controllers that terminate a
 >> overlay tunnel
 > typo: an overlay

OK

 >> o  In a datacenter, where VM mobility and VM address reslution also
 > typo: resolution

Thanks,
    Erik

 > Dan

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 19 Nov 2013 19:54:37 +0100

Hi Ray,

> 
> Ole Troan wrote:
> > All,
> >
> > We reconsidered the action from Vancouver, and decided to have the
> discussion on this draft as part of the adoption call instead.
> > Please provide a view with reasons as to whether the WG should adopt
this
> or not.
> I think the security considerations should at least address the following
> elements.
> 
> The protocol to boot network connectivity (learn neighbours) is dependent
> on correct time synchronisation between all nodes on the link.

We all know that even the DNSSEC has the problem of time synchronization but
this does not effect on its deployment process. Here also the solution might
be simple. The earliest version of this draft introduced a local RPKI model
however, based on the comments of Michael,  I separate that section to a new
draft. This local RPKI also can play a role of time synchronizer and
mitigate this attack.

> The protocol to boot network connectivity (learn neighbours) is dependent
> on all nodes obtaining the public key of the neighbor. The draft does not
> address how a node that is first joining the network can bootstrap RPKI or
how
> the public key is distributed.

RPKI is actually useful for routers. Since this approach prove the IP
address ownership as explained in the draft, when any nodes join to the
network, it generates its IP address and other nodes accept him after a
successful verification. 
This nodes also learn about other nodes by verifying them. This approach
gives a way to the nodes to know nobody is actually spoof the IP address of
others.

> The protocol to boot network connectivity (create a tentative address) is
> dependent on trusting RA. Any attack on RA would be an attack on the
> protocol.

As I explained before you need that simple RPKI for routers. The problem is
that you just limited your view to the local security. Now here I ask you to
widen your view for many different possible use cases in different possible
scenarios. This approach can be used in many different scenarios and
integrate with application layer protocols. Actually recently there was a
discussion offlist about a work of someone to integrate the SSAS with SIP as
a way of authentication and prove of IP address ownership as they needed a
fast approach. As I discussed with Dan, he also clarified this and explained
about the possible use of this approach for SIP proxies. So what is clear
here is we need a fast secure approach to secure many scenarios in different
layers. If CGA was ok (from operational aspects, complexity, etc) why not it
is widely implemented after several years?. We all know that we are not
looking for complexity but a simple way to solve our problem and this is the
focus of this draft. I also integrate it with DNS security and it is really
a way for end point authentication since it is not DNSSEC to use DNSSEC for
client to resolver authentication or etc. but something like this simply can
be used as a means of authentication.

> Compute intensity of CGA was "by design." Any reduction in compute
intensity
> should be regarded with suspicion.

I actually had this discussion with some security guys. So, I do not see any
further discussion here.

> Replay attacks can occur very quickly. A time window of a "short period of
> time" could be an eternity on a LAN.

I just considered it based on the network policy and it is really a short
window. However,  based on another recent comment I am going to set it to
RTT as a default value.

> DoS attacks could still overwhelm any node. It's a lot easier to send junk
than
> to check a signature, even with the reduced receiving-algorithm complexity
> proposed in SSAS verification.

> Equally an attacker could send unlimited "correct" neighbour registration
> packets (up to 2^64) from a single node that pass all the way to step 9 of
the
> verification process, leading to resource depletion of the neighbour cache
or
> key cache on all nodes on the LAN.

I showed the mitigation approach. We all know that DoS attack can be
mitigated but cannot completely prohibited. You can have this attack on
every other approaches either they are using secure or not. It does not
matter for DoS attack. Our approach is as fast as if DoS attack happens it
will like the case you did the DoS attack on the  NDP protocol or DNS
protocol.  So, the case is that this attack can also happen when you are not
using security. 
So, what I guess you are thinking here is like the case where someone says
we have to stop eating because we think that we will die one day so why
should we do any effort?. You are thinking about worse cases. What I say is
that we have to do all our efforts to provide security either local or
global and think about mitigation approach as much as possible.
 
> collisions for every single packet on demand, or confuse the bridge CAM

Here I had a mitigation solution to this attack, however, since it is layer
2 attack, we can prevent it by using my local RPKI node also as a monitoring
system that collects, IP, public key and MAC address of the nodes and so
other nodes ask him about the correct MAC address and synchronize themselves
with him. 
Our mitigation scenario is that we included the MAC address also to the
signature. This means that the nodes know this IP address MIGHT be
associated to this MAC address. If the bad guy spoof the MAC address of the
other guy, It cannot spoof the IP address and say that I am with this IP
have A MAC. This is also a warning signal to the nodes to detect the
attacker since they receive two request with DIFFERENT IP addresses but with
the same MAC. If you feel more convenient, you can also use the RPKI node as
a monitoring system like my proposal for RPKI. 
Another possible case to detect the attacker is that, I check the
reachability cache. Since the attacker is trying to perform several attacks
at the same time. He might use different MAC address with different IP or
even the same IP. If it is the same IP, then I would detect him. If not, the
Reachability checks fails and I remove that bad guy from my neighboring
cache. 

But actually the case is that, when two nodes communicating to each other,
they use their IP addresses or domain names. I am talking about applications
and when I check for neighbor reachability. 

> L2 link then all bets are off. If you're worried about such attacks then
there
> are existing technologies to address this e.g. point to point links in
wireless,
> private VLANs, or limiting the number of IPv6 prefixes and addresses per
port
> in the switch hardware.

I do not like to repeat myself as I have already explained the reasons in
the previous paragraph. I was talking the case where the attacker accessed
one of the legitimate nodes (virus, etc) inside your network. Do you think
the WLAN SSID here really helps? The attacker is not around. Doesn't need to
have your SSID. It is the same as the case where you limit the IPv6
prefixes. I agree to some extend with MAC spoofing and I explained the
mitigation or prevention approach but what you explained here does not
really discuss about whether this approach is good or bad. 

I just want to add this important point here; the purpose of SSAS proposal
is not only the local security (but its priority is) but I am thinking about
a wide use case scenarios for authentication and prove of IP address
ownership beyond the local network especially when proxy servers are used
and have no clue of the nodes communicating to. This can be a way to ensure
to the both end point communications, not necessarily in one network, but
also it can be in two/more different networks that the one they are
communicating with is actually the owner of that IP address. Why, because it
is easier to just have an access list based on the IP addresses rather than
have an access list based on their public keys on my proxy servers. It is
the same as in application layer. 

If you think, you can find many different use case for this proposal.

Thanks,
Smile,
Hosnieh

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Nov 2013 11:51:57 -0800

Ray,

Thanks for all these comments - I think they can be used to improve the 
draft and the protocol.

> I have read the draft and I'm sceptical.

Are you saying that the WG shouldn't take on this document because some 
work remains to be done? (which your comments clearly indicates.) 
Normally WGs that on documents in order to do work. By WG last call the 
WG would make sure they are happy with the completeness of the document.

Or are you saying that the WG shouldn't bother with security in and 
around ND? Or that this document is heading in the completely wrong 
direction? I'm puzzled and asking for clarifications.

> potentially deny service to all nodes.

How would it deny service to all? Are you thinking of a case when all 
timestamps are considered to be old due to an attack on a time protocol?

Perhaps SSAS should use the nonce approach in SeND for packets that 
solicit responses. That can handle a NS-NA and RS-RA exchange without 
relying on synchronized time.

With such an approach the residual threat is due to unsolicited RAs and 
NAs, and an attacker would have the ability to either have such be 
dropped (due to spoofing the time protocol), or inject replays of stale 
information (such as an old unsolicited NA with a old mac address).

Even though SeND didn't do that, one could envision following an 
unsolicited RA/NA which causes a state change on the receiver with a 
solicitation. Thus the (uncommon case) of an unsolicited NA with a new 
MAC address would become a (multicast NA) followed by a unicast NS/NA 
from every host which would change its neighbor cache entry.
I don't know if that is worth-while. Some of us are trying to move away 
from periodic unsolicited RAs, which means less unsolicited info.

> bootstrap RPKI or how the public key is distributed.

For the host-to-host part of SSAS (just like SeND/CGA) the public key is 
exchanged as part of the NS/NA. The RPKI hooks are not part of this 
draft AFAIK.

> intensity should be regarded with suspicion.

My understanding is that SSAS reduces the unneeded work and in doing so 
strengthens the base security over CGA in two ways:
  - 62 instead of 59 bits of hash (and I think that can be 64 and not 62)
  - only the initial contact depends on the security of the 62 bits - 
after than the public key is in the neighbor cache

Reducing the CPU needed to generate an IID and verify a NA is goodness; 
it increases the likelyhood that we can get wide-spread deployment of 
security for ND and also makes it more tractable to change IIDs when a 
host moves to a different link/prefix (and the latter is good for privacy).

> receiving-algorithm complexity proposed in SSAS verification.

I don't understand what you are proposing as a remedy. Please clarify.
Is it to be more explicit about the residual threads in the security 
considerations section?

> of the neighbour cache or key cache on all nodes on the LAN.

Filling up the neighbor cache is not new in this draft. RFC 4861 (and 
ARP for that matter) allows for that. Implementations need to manage 
their memory in all of those cases.

The fundamental questions are about the assumed resources of an 
attacker, and whether the attacker cares about detection.
A very resourceful attacker could generate a lot (up to 2^64) 
public/private key pairs and send correct NS messages from those addresses.

It makes sense to state such residual threats in the security 
considerations section.

> prefixes and addresses per port in the switch hardware.

That are potential attackers on every L2 link. Might be slightly 
different in the coffee shop, university campus, or office LAN. Setting 
up point-to-point wireless links typically only solves part of the 
problem, because that wireless link is often bridged by an AP onto a 
normal LAN.

While I realize that there are some L2-specific threats relating to 
LANs, I think we should face the reality that there are LANs and we 
should reduce the attack surface especially for trivial and hard to 
notice attacks like spoofing someones IP address.

The alternative would be to tell the world that there is a choice 
between a secure infrastructure and a LAN and they have to chose - 
because we collectively don't think we can improve the security of LAN 
protocols. That doesn't make sense to me personally.

My 2 cents,
    Erik

---

From: Ray Hunter <[email-masked]>
Date: Tue, 19 Nov 2013 22:06:31 +0100

> Erik Nordmark <mailto:[email-masked]>
> 19 November 2013 20:51
> Ray,
>
> Thanks for all these comments - I think they can be used to improve
> the draft and the protocol.
>
> Are you saying that the WG shouldn't take on this document because
> some work remains to be done? (which your comments clearly indicates.)
> Normally WGs that on documents in order to do work. By WG last call
> the WG would make sure they are happy with the completeness of the
> document.
Sure. But after reading the draft, and the reply from Hosnieh, I'm
really left wondering what exactly the problem is that we're trying to
solve.

That's my biggest issue with adopting this draft as a WG item. Not that
it isn't "RFC editor ready".
> direction? I'm puzzled and asking for clarifications.
I'm saying that the draft claims to cure some problems, but it is my
opinion that many of those problems cannot be solved at layer 3, without
at least some other mitigation measures being applied at layer 2 or
elsewhere in the infrastructure.

So what are we trying to achieve with this draft?

> timestamps are considered to be old due to an attack on a time protocol?
Yes. Too old or too new. In any case, outside of the sliding window.

> With such an approach the residual threat is due to unsolicited RAs
> and NAs, and an attacker would have the ability to either have such be
> dropped (due to spoofing the time protocol), or inject replays of
> stale information (such as an old unsolicited NA with a old mac address).
>
Yes. You lose whichever way you look at it, unless you come up with
something like a one-time-use-password, based on applying n multiple
hashes to a shared secret, that is negotiated at some point by some
magic exchange, and where n is decremented each time the password is
used, and where n is tracked.

> I don't know if that is worth-while. Some of us are trying to move
> away from periodic unsolicited RAs, which means less unsolicited info.
>
Yes.

> For the host-to-host part of SSAS (just like SeND/CGA) the public key
> is exchanged as part of the NS/NA. The RPKI hooks are not part of this
> draft AFAIK.
>
Ack.

> My understanding is that SSAS reduces the unneeded work and in doing
> so strengthens the base security over CGA in two ways:
> Reducing the CPU needed to generate an IID and verify a NA is
> goodness; it increases the likelyhood that we can get wide-spread
> deployment of security for ND and also makes it more tractable to
> change IIDs when a host moves to a different link/prefix (and the
> latter is good for privacy).
>
I don't think you can remedy this attack vector solely at layer 3 on end
nodes and routers, and still have a usable protocol that allows nodes to
arrive and register in LANs in a flexible manner. One solution I have
seen used elsewhere is for the switching infrastructure to place people
in a parking/registration LAN until they prove their credentials, and
then move them to the production segment/VLAN.

> Is it to be more explicit about the residual threads in the security
For starers. Yes.

> their memory in all of those cases.
True. But this draft explicitly claimed it addressed the DoS problem.

> public/private key pairs and send correct NS messages from those
Exactly my point.

> different in the coffee shop, university campus, or office LAN.
> Setting up point-to-point wireless links typically only solves part of
> the problem, because that wireless link is often bridged by an AP onto
> a normal LAN.
>
We still have existing solutions, like 802.1X. They are not easy to
deploy, but they are already widely supported.

And what precisely is wrong with SEND?

-- 
Regards,
RayH

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 19 Nov 2013 22:31:01 +0100

> Sure. But after reading the draft, and the reply from Hosnieh, I'm really
left
> wondering what exactly the problem is that we're trying to solve.

Have I ever mentioned that I do not improve the draft with the comments I
receive/received that you have such interpretation? 

> That's my biggest issue with adopting this draft as a WG item. Not that it
isn't
> "RFC editor ready".

> I'm saying that the draft claims to cure some problems, but it is my
opinion
> that many of those problems cannot be solved at layer 3, without at least
> some other mitigation measures being applied at layer 2 or elsewhere in
the
> infrastructure.

Local security as a first step and also look at it as a means for
application layer authentication or prove of IP address ownership wherever
it is needed. I refer you to my last message.

> something like a one-time-use-password, based on applying n multiple
hashes
> to a shared secret, that is negotiated at some point by some magic
exchange,
> and where n is decremented each time the password is used, and where n is
> tracked.
> 
> >> draft does not address how a node that is first joining the network
> >> can bootstrap RPKI or how the public key is distributed.
> >
> >> The protocol to boot network connectivity (create a tentative
> >> address) is dependent on trusting RA. Any attack on RA would be an
> >> attack on the protocol.
> >>
nodes
> and routers, and still have a usable protocol that allows nodes to arrive
and
> register in LANs in a flexible manner. One solution I have seen used
> elsewhere is for the switching infrastructure to place people in a
> parking/registration LAN until they prove their credentials, and then move
> them to the production segment/VLAN.
> 
> 
> >> registration packets (up to 2^64) from a single node that pass all
> >> the way to step 9 of the verification process, leading to resource
> >> depletion of the neighbour cache or key cache on all nodes on the LAN.
> >

In draft it is said, one can MITIGATE this attack not prevent it. Did I say
anywhere in the draft that I miss it? If so where?

> >> collisions for every single packet on demand, or confuse the bridge
> >> CAM table.
> >>
> >> L2 link then all bets are off. If you're worried about such attacks
> >> then there are existing technologies to address this e.g. point to
> >> point links in wireless, private VLANs, or limiting the number of
> >> IPv6 prefixes and addresses per port in the switch hardware.
> >
deploy, but
> they are already widely supported.

Just from Internet:
"Not all devices support 802.1X authentication: examples are network
printers, ethernet-based electronics like environmental sensors, cameras,
wireless phones etc. For those devices to be used in a protected network
environment, alternative mechanisms must be provided to authenticate
them..."

This is another place to use SSAS.

> And what precisely is wrong with SEND?

SSAS is actually an option of SeND, however, it can be used with other
protocols as well for security purposes. 

Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 19 Nov 2013 23:06:19 +0100

Follow up,
 Something came to my mind as a solution to address you concern for MAC
address spoofing and attacks on link layer without the use of RPKI (not
talking about routers again, for routers it is required).

For link layer attack and mac spoofing. What if we place part of hash of the
public key as a MAC address. This means a node has a dynamic mac address. So
the node will announce his new MAC with setting his new IP address. The node
would have a dynamic MAC. Only the problem here would be many IP addresses
on one Interface ID. I guess for that solution also the other IP addresses
can take other parts of the same public key and use it so that we only use
one public key.  

I asked Ted and he said it is possible to have dynamic MAC. Just the problem
would be the collision MAC addresses. Since we assume that all nodes are
using SSAS inside the same network. I guess the probability is really low. 

-----------smile----------
Hosnieh
. success is a journey, not a destination..
You cannot change your destination overnight, but you can change your
direction ... Focus on the journey

-

---

From: Dan Wing <[email-masked]>
Date: Tue, 19 Nov 2013 14:17:14 -0800

> using SSAS inside the same network. I guess the probability is really low. 

If a required step for deployment is, "first, upgrade all hosts to $FOO", and there is no gain until all hosts have been upgraded, successful deployment is really really hard.

-d

---

From: Christian Huitema <[email-masked]>
Date: Tue, 19 Nov 2013 23:54:14 +0000

The draft starts by expressing the author's personal opinion about CGA, namely:

1) That it is possible to mount a denial of service attacks by asking the receiver to verify a large number of CGA addresses;

2) And, that generating secure CGA addresses requires an important CPU investment;

The proposed solutions are:

1) To update the CGA generation algorithms to use ECC instead of RSA cryptography;

2) To replace the hash-based generation of IID in CGA by a direct extractions of bits from the public key;

3) To derive all 64 IID bits from the key, instead of just 59 in CGA, doing away with the "sec" field and the u/g bit;

The IID algorithm proposed by the author is trivially spoofed using pre-computed keys. Suppose that a well-funded attacker has generated a catalog of public keys. It can then trivially search that catalog for keys that match the 64 bit pattern in the IID. The main defense against that attack is the supposed long computation time for key generation, but that seems like a weak defense as ECC keys are not very hard to generate once the curve is known. Given that, one has to wonder whether the algorithm is a proper replacement for CGA.

The simple verification algorithm is central to the claim that the solution has better DOS resistance than current CGA, because extracting and comparing 64 bits will be faster than computing and comparing a secure hash. This assumes that the hash computation time is the dominant factor in the validation process, compared to message transmission and processing and other data extraction. There is no proof that this is indeed the case. DOS is indeed a problem in all protocols, but the classic solutions involve filtering and rate limiting. Even with instantaneous comparisons, there will still be a need for these classic solutions.

In practice, we are seeing very limited deployment of SEND and CGA. Before we start WG work on improving this solution, we may want to hear from actual deployments, and their requirements.

-- Christian Huitema

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Nov 2013 16:41:15 -0800

> So what are we trying to achieve with this draft?

Let me take a concrete example around address spoofing stealing.

In a normal Ethernet network there are learning 802.1Q bridges. Thus 
packets destined to a given MAC address can be stolen by having the 
attacker emit packets (typically broadcast to make sure all relevant 
bridges see them) with the spoofed source MAC. That will make the 
bridges send packets to the attacker.

However, the owner of the MAC address will most likely continue to send 
some packets, which will cause the bridges to flip flop. If the attacker 
wants to be a MiTM (e.g., to be a MiTM for some e2e security protocol) 
the attacker needs to send a fairly steady rate of spoofed packets. That 
results in lots of flip-flops in the bridges.

Those flip flops might trigger alarms. And I suspect there are also 
products that allow the admin to lock down MAC addresses - limit the 
number of flip flops - but I haven't studied that part.

With IPv6 ND an attacker can instead attack the IPv6->MAC binding by 
sending a single NS or NA. The NCEs will be updated with that MAC 
address. And the way NUD works this entry will not be timed out. As long 
as the routers (and other hosts on the link) do not run out of space in 
their neighbor cache and delete the entry it can stay in the spoofed 
state for a long time. However, if the target host sends a NS from that 
IPv6 address then the NCE can be restored - lot less likely to happen 
than the target sending any packet and getting the bridge to re-learn.

One might ask whether we wouldn't need a fix for IPv4/ARP. But in 
reality for the interesting LANs (LANs that are open to the public or 
visitors) the addresses are assigned using DHCP. And there are 
commercial products which snoop DHCP to bind an IPv4 address to a port 
to prevent stealing the address after it has been assigned by DHCP.

In IPv6 we want to allow the hosts to generate their own addresses (for 
instance, for improved privacy using temporary addresses of some form). 
For that reason (and perhaps others) we can't just remove SLAAC and 
require everybody to use DHCPv6 and use the IPv4 DHCP approach.

What we'd want is that if a user goes to the effort to log and/or 
prevent attempts at mac address spoofing at L2, and deploys DHCPv4 
snooping for IPv4, that there exists a tool for IPv6 which solves the 
same problem. If we don't have this, then IPv6 would be the weakest link 
in the chain.

Providing a deployable tool (which includes being efficient enough to 
enable hosts to change their IID on movement to avoid privacy concerns) 
is IMO what this draft sets out to solve.

> arrive and register in LANs in a flexible manner.

Correct - L3 can't solve all security problems. But we need to make sure 
that in a security-concious deployment, IPv6 at L3 isn't the weakest 
link with no available tool.

> One solution I have

I can see how that can solve handling employees vs. guests in e.g., an 
enterprise network. But I don't see how it would help with attacks among 
a given set (be the set the public in a coffee shop, or different guests 
in the same enterprise network). Once they are on the production VLAN 
they can spoof each other.

The IETF has a solution from the SAVI working group which, if 
implemented and deployed, would help somewhat. But for reasonable 
protection that solution requires all the access ports (including APs 
viewing the associations as virtual ports) to track the bindings. And 
for SLAAC it is just a first-come first-serve in terms of claiming an 
IPv6 address.

> deploy, but they are already widely supported.

802.1x doesn't prevent IP address stealing - neither for IPv4 nor for 
IPv6. I don't even think it prevents MAC address stealing - at least the 
802.1x specification doesn't talk about MAC addresses but instead is 
merely about authenticating a (virtual) port.
Which problem are you solving?

> And what precisely is wrong with SEND?

Different topic - so far you've argued that we don't need to solve this, 
because either somehow some L2 solution will solve it (which I hope I've 
shown it can't) or that the problem is not important or too difficult to 
solve.
The SeND comment seems to imply that you think the problem is important 
to solve at L3. If you have been convinced that it is, then I think 
there is some text in the draft (and emails in the archive) which 
discuss the comparison with SeND.

Regards,
    Erik

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 20 Nov 2013 08:04:05 +0100

Hi,
> 1) That it is possible to mount a denial of service attacks by asking the
receiver
> to verify a large number of CGA addresses;
> 
> 2) To replace the hash-based generation of IID in CGA by a direct
extractions
> of bits from the public key;
> 
> 3) To derive all 64 IID bits from the key, instead of just 59 in CGA,
doing away
> with the "sec" field and the u/g bit;
> 
> The IID algorithm proposed by the author is trivially spoofed using pre-
> computed keys. Suppose that a well-funded attacker has generated a catalog
> of public keys. It can then trivially search that catalog for keys that
match the
> 64 bit pattern in the IID. The main defense against that attack is the
supposed
> long computation time for key generation, but that seems like a weak
defense
> as ECC keys are not very hard to generate once the curve is known. Given
> that, one has to wonder whether the algorithm is a proper replacement for
> CGA.
> 
> The simple verification algorithm is central to the claim that the
solution has
> better DOS resistance than current CGA, because extracting and comparing
> 64 bits will be faster than computing and comparing a secure hash. This
> assumes that the hash computation time is the dominant factor in the
> validation process, compared to message transmission and processing and
> other data extraction. There is no proof that this is indeed the case. DOS
is
> indeed a problem in all protocols, but the classic solutions involve
filtering and
> rate limiting. Even with instantaneous comparisons, there will still be a
need
> for these classic solutions.
> 
> In practice, we are seeing very limited deployment of SEND and CGA. Before
> we start WG work on improving this solution, we may want to hear from
actual
> deployments, and their requirements.
> 
> -- Christian Huitema
> 

I am sorry to say this but your evaluation and your understanding from this
draft is not correct.

Reasons that SeND is not widely implemented is because SeND without CGA
secure option is not secure and it just increase complexity while it cannot
really do its job to protect the nodes.
Reasons that CGA is not widely implemented:.
- Most features that implementers would like to implement is because they
want also to benefit from it. But does CGA IPR allows  you to make money out
of it. It is royalty free for charity implementation.
- CGA only added the complexity of address generator. Really, do you wish to
wait for about 3 hours to years to generate an IP address?! Or just busy
your CPU with a hope of IP address generation instead of using it
efficiently for other processes and programs in your computer?!
- Your evaluation from SSAS is wrong. It has the security of the whole
public key and not a part of that, I refer you to the draft.

-----------smile----------
Hosnieh

---

From: Ray Hunter <[email-masked]>
Date: Wed, 20 Nov 2013 08:59:18 +0100

> 20 November 2013 01:41
> However, the owner of the MAC address will most likely continue to
> send some packets, which will cause the bridges to flip flop. If the
> attacker wants to be a MiTM (e.g., to be a MiTM for some e2e security
> protocol) the attacker needs to send a fairly steady rate of spoofed
> packets. That results in lots of flip-flops in the bridges.
>
They exist, and are widely deployed.
> address. And the way NUD works this entry will not be timed out. As
> long as the routers (and other hosts on the link) do not run out of
> space in their neighbor cache and delete the entry it can stay in the
> spoofed state for a long time. However, if the target host sends a NS
> from that IPv6 address then the NCE can be restored - lot less likely
> to happen than the target sending any packet and getting the bridge to
> re-learn.
>
> In IPv6 we want to allow the hosts to generate their own addresses
> (for instance, for improved privacy using temporary addresses of some
> form). For that reason (and perhaps others) we can't just remove SLAAC
> and require everybody to use DHCPv6 and use the IPv4 DHCP approach.
>
I don't see why not in many operating environments (where the user
trusts the infrastructure)
IPv4 + DHCP has been rather successful in the market.
> same problem. If we don't have this, then IPv6 would be the weakest
> link in the chain.
>
> enable hosts to change their IID on movement to avoid privacy
> concerns) is IMO what this draft sets out to solve.
>
The comparison to IPv4 is rather disingenuous.

If we were comparing like with like, we'd find that DHCPv6 can also
provide signing of the content, can also assign temporary addresses, and
there are DHCPv6 snooping solutions on the market that provide
equivalent functionality to that available with DHCP (v4). So the
enterprise trust model is pretty much covered IMHO.

What we now seem to be considering is attempting to secure the
equivalent of self-assigned addresses (RFC 3927), for which there is no
solution in IPv4.

> Correct - L3 can't solve all security problems. But we need to make
> sure that in a security-concious deployment, IPv6 at L3 isn't the
> weakest link with no available tool.
>
Agreed.
> enterprise network. But I don't see how it would help with attacks
> among a given set (be the set the public in a coffee shop, or
> different guests in the same enterprise network). Once they are on the
> production VLAN they can spoof each other.
>
If you're in a coffee shop or on a public guest LAN, all bets are off.

Once your device leaves the coffee shop, someone can still spoof you, or
perform a mitm attack, or replay your entire application level traffic,
without there being any conflict, unless the protocol provides adequate
protection that couples into the underlying infrastructure or secures
the end to end path (which it currently doesn't because the coffee shop
AP device could itself be rogue).

If the problem space is the coffee shop, then you're probably better off
simply tunnelling all of your traffic to a trusted proxy at your home
base using IPSec or mobile IPv6. And if the guest LAN is "down", move to
another.
> IPv6. I don't even think it prevents MAC address stealing - at least
> the 802.1x specification doesn't talk about MAC addresses but instead
> is merely about authenticating a (virtual) port.
>
I'd like the WG to address the underlying operational problems with ND
identified in http://tools.ietf.org/html/rfc6583.
If this draft achieves that (and possibly even more), then I'd
definitely support it.

> Different topic - so far you've argued that we don't need to solve
> this, because either somehow some L2 solution will solve it (which I
> hope I've shown it can't) or that the problem is not important or too
> difficult to solve.
> The SeND comment seems to imply that you think the problem is
> important to solve at L3. If you have been convinced that it is, then
> I think there is some text in the draft (and emails in the archive)
> which discuss the comparison with SeND.
>
> Regards,
>    Erik
>
Disagree. IMHO It is exactly the topic. There is an existing solution
(which may or may not be perfect) that covers the same or similar
problem space.
Before we go tinkering with it, I'd like to understand why it needs
changing.

I really can't imagine that CPU horsepower on its own is the main reason
why SEND is not widely deployed.

-- 
Regards,
RayH

---

From: Warren Kumari <[email-masked]>
Date: Wed, 20 Nov 2013 09:33:30 -0300

> Please provide a view with reasons as to whether the WG should adopt this or not.

I do not support adoption.

I do not view this as actually *solving* a *real* issue….

W

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--
Consider orang-utans.
In all the worlds graced by their presence, it is suspected that they can talk but choose not to do so in case humans put them to work, possibly in the television industry. In fact they can talk. It's just that they talk in Orang-utan. Humans are only capable of listening in Bewilderment.
-- Terry Practhett

---

From: Warren Kumari <[email-masked]>
Date: Wed, 20 Nov 2013 09:54:18 -0300

> If a required step for deployment is, "first, upgrade all hosts to $FOO", and there is no gain until all hosts have been upgraded, successful deployment is really really hard.

Especially if $FOO is not solving an active problem *that people care about*…

W

>> direction ... Focus on the journey

In fact, the mere act of opening the box will determine the state of the cat, although in this case there were three determinate states the cat  could be in: these being Alive, Dead, and Bloody Furious. 
-- Schrodinger's Moggy explained 
(Terry Pratchett, Lords and Ladies)

---

From: Hosnieh <[email-masked]>
Date: Wed, 20 Nov 2013 08:04:21 -0500 (EST)

> I do not view this as actually *solving* a *real* issue….

What is the real issue from your aspect that this document didn't cover it?
explain your reasons please and do not just say I support or not support since
it doesn't much help and does not show whether not you read or understood the
purpose of document. Probably we can include it if it is something reasonable.

Smile,
Hosnieh

---

From: Hosnieh <[email-masked]>
Date: Wed, 20 Nov 2013 08:19:56 -0500 (EST)

> IPv4 + DHCP has been rather successful in the market.

The problem is that you always think none of your node in the network can be or
will be malicious.

In a big enterprise it means you trust all the staff and say that none of them
will try to warn my network. it is really an optimistic thinking.  You really
wonder me sometimes. Because sometimes, you think pasimistics and sometimes so
optimistic.
Let's have a very realistic example. if the US government (x) didn't really
trust  Edward Snowden then he didn't have a chance to access many confidential
data!!

Now let's back to DHCPv6. Besides the security problem that Erik mentioned here.
If you're thinking about management, you can easily  have STATELESS DHCPv6 and
do not sacrifice the security of your ndoes. This means that let your nodes
configure their IP address but your server only keep the status of IP addresses
and send the DNS and routing parameters to the nodes. let' your nodes have their
own security and if you are interested, let your DHCP server also keep the
status of node after verifying them.

> why SEND is not widely deployed.

For this please refer to my answer to Christian.

Smile,
Hosnieh

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Nov 2013 09:29:03 -0500

Erik Nordmark <[email-masked]> wrote:
    > What we'd want is that if a user goes to the effort to log and/or prevent
    > attempts at mac address spoofing at L2, and deploys DHCPv4 snooping for IPv4,
    > that there exists a tool for IPv6 which solves the same problem. If we don't
    > have this, then IPv6 would be the weakest link in the chain.

I concur.

And, given the expense of those systems to lock/prevent mac-address spoofing
(not even possible/relevant on wifi) and special DHCPv4 servers, secure
addresses in IPv6 would be much cheaper, and therefore more likely to be
used.

I think that the SSAS document makes SEND easier to use, and I think
we should adopt it.

    > Correct - L3 can't solve all security problems. But we need to make sure that
    > in a security-concious deployment, IPv6 at L3 isn't the weakest link with no
    > available tool.

+1

I think of this as SENDbis.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Nov 2013 15:34:25 +0000

Hi,

I think it might be good to split out the new CGA algorithm and the IP spoofing protection part into two separate drafts.  I find the existing draft hard to read in many places.  Further, the introduction is a wall of text about SLAAC that is not really the focus.

If split, the former can present the new algorithm, and how it improves on existing CGA.

The latter can present a short overview of the existing spoofing protection issues (drawn from in part the comments made below) and define how the new address type can provide protection.

I'd note that CGA and SeND are separate RFCs.

It would also be good to check the scope of the IPR on RFC 3972 (CGAs), to ensure it doesn't prevent "similar" algorithms being used.  On the basis that it's being argued that the IPR claim is hampering implementations.  For reference, the 3972 IPR statements are here:
https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3972

Tim

On 20 Nov 2013, at 00:41, Erik Nordmark <[email-masked]> wrote:

> In a normal Ethernet network there are learning 802.1Q bridges. Thus packets destined to a given MAC address can be stolen by having the attacker emit packets (typically broadcast to make sure all relevant bridges see them) with the spoofed source MAC. That will make the bridges send packets to the attacker.
> 
> However, the owner of the MAC address will most likely continue to send some packets, which will cause the bridges to flip flop. If the attacker wants to be a MiTM (e.g., to be a MiTM for some e2e security protocol) the attacker needs to send a fairly steady rate of spoofed packets. That results in lots of flip-flops in the bridges.
> 
> Those flip flops might trigger alarms. And I suspect there are also products that allow the admin to lock down MAC addresses - limit the number of flip flops - but I haven't studied that part.
> 
> With IPv6 ND an attacker can instead attack the IPv6->MAC binding by sending a single NS or NA. The NCEs will be updated with that MAC address. And the way NUD works this entry will not be timed out. As long as the routers (and other hosts on the link) do not run out of space in their neighbor cache and delete the entry it can stay in the spoofed state for a long time. However, if the target host sends a NS from that IPv6 address then the NCE can be restored - lot less likely to happen than the target sending any packet and getting the bridge to re-learn.
> 
> One might ask whether we wouldn't need a fix for IPv4/ARP. But in reality for the interesting LANs (LANs that are open to the public or visitors) the addresses are assigned using DHCP. And there are commercial products which snoop DHCP to bind an IPv4 address to a port to prevent stealing the address after it has been assigned by DHCP.
> 
> In IPv6 we want to allow the hosts to generate their own addresses (for instance, for improved privacy using temporary addresses of some form). For that reason (and perhaps others) we can't just remove SLAAC and require everybody to use DHCPv6 and use the IPv4 DHCP approach.
> 
> 
> What we'd want is that if a user goes to the effort to log and/or prevent attempts at mac address spoofing at L2, and deploys DHCPv4 snooping for IPv4, that there exists a tool for IPv6 which solves the same problem. If we don't have this, then IPv6 would be the weakest link in the chain.
> 
> Providing a deployable tool (which includes being efficient enough to enable hosts to change their IID on movement to avoid privacy concerns) is IMO what this draft sets out to solve.
> 
> Correct - L3 can't solve all security problems. But we need to make sure that in a security-concious deployment, IPv6 at L3 isn't the weakest link with no available tool.
> 
>> One solution I have
> I can see how that can solve handling employees vs. guests in e.g., an enterprise network. But I don't see how it would help with attacks among a given set (be the set the public in a coffee shop, or different guests in the same enterprise network). Once they are on the production VLAN they can spoof each other.
> 
> 
> The IETF has a solution from the SAVI working group which, if implemented and deployed, would help somewhat. But for reasonable protection that solution requires all the access ports (including APs viewing the associations as virtual ports) to track the bindings. And for SLAAC it is just a first-come first-serve in terms of claiming an IPv6 address.
> 
> 802.1x doesn't prevent IP address stealing - neither for IPv4 nor for IPv6. I don't even think it prevents MAC address stealing - at least the 802.1x specification doesn't talk about MAC addresses but instead is merely about authenticating a (virtual) port.
> Different topic - so far you've argued that we don't need to solve this, because either somehow some L2 solution will solve it (which I hope I've shown it can't) or that the problem is not important or too difficult to solve.
> The SeND comment seems to imply that you think the problem is important to solve at L3. If you have been convinced that it is, then I think there is some text in the draft (and emails in the archive) which discuss the comparison with SeND.
> 
> Regards,
>   Erik
> 
>

---

From: Hosnieh <[email-masked]>
Date: Wed, 20 Nov 2013 10:53:13 -0500 (EST)

Hi Tim,

Thanks for your comments.Actually the problem now is my rfc editor.  I am
working on it because I need to add new features so that I can have a formatted
appendices. Following the mailing list and at the same time focus on programming
is not easy :-) (I spread myself too much) since the WG is just have this
adoption call for a week. I do not know why only a week and not a month since
many people that I talked to are not free to contribute to the mailing list. The
folks like Suresh, Derek. etc.
Anyway, IP spoofing is a part of IP address ownership so if I put it in a
separate document, I guess it will confuse the purpose of this draft more. But I
agree that the text need more organization that hopefully I do it as soon as I
finish this editor.

About IPR, I actually consulted with a patent advisor. I just explained that
sentence based on my recent information from a lawyer during a patent workshop
at my university as I was so curious about the patents and their scope.
What I understood is that I am free to use a patent products for charity sake
but if I am going to make money out of it, I have to pay to the owner of the
patent.

SSAS does not follow CGA algorithm. What I also learned about patents is that
one can change a part of a product and use it. He should have enough reason to
say the differences with the original product. Since I have not copy or follow
the CGA algorithm, it does not follow the patent or in IETF terms, IPR and SSAS
idea is just a wild idea.

Thanks,

> On November 20, 2013 at 10:34 AM Tim Chown <[email-masked]> wrote:
> 
>  Hi,
> 
>  I think it might be good to split out the new CGA algorithm and the IP
> spoofing protection part into two separate drafts.  I find the existing draft
> hard to read in many places.  Further, the introduction is a wall of text
> about SLAAC that is not really the focus.
> 
>  The latter can present a short overview of the existing spoofing protection
> issues (drawn from in part the comments made below) and define how the new
> address type can provide protection.
> 
>  It would also be good to check the scope of the IPR on RFC 3972 (CGAs), to
> ensure it doesn't prevent "similar" algorithms being used.  On the basis that
> it's being argued that the IPR claim is hampering implementations.  For
> reference, the 3972 IPR statements are here:
> <https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3972>
> 
>  Tim
> 
> 
Smile,
H
Hosnieh

---
Hosnieh
Sorry for tpyos from my chubby fingers typing on my phone

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Nov 2013 08:22:54 +1300

On 21/11/2013 04:53, Hosnieh wrote:
...
> but if I am going to make money out of it, I have to pay to the owner of the

I suspect you need a new lawyer. In any case, it doesn't matter, since
my observation is that most Internet-related products are not donated
to charity.

    Brian

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 20 Nov 2013 21:10:29 +0100

Hi Brian,

> > What I understood is that I am free to use a patent products for
> > charity sake but if I am going to make money out of it, I have to pay
> > to the owner of the patent.
> 
> I suspect you need a new lawyer. In any case, it doesn't matter, since my
> observation is that most Internet-related products are not donated to charity.
> 
>     Brian

I guess we are saying the same thing but in different ways and I do not think that I need to change my lawyer. Probably my way of saying is not correct. If you implement the patented idea but you're not looking for selling it then you have no problem. But, if you are going to sell it, you would need first to pay for the idea you used, to the owner, and then start advertising it and sell it. Recently there was a headline of the news about an epidemic virus with the name "nCoV-EMC" that the similar version was patented by a British medical institute and no research institutions around the world were willing to work on that because they weren’t sure that who will benefit from this research and how they can support this research financially. The medical industries just willing to support this project if and if they could later sell the vaccination. Anyway, fortunately in IT, our work in most cases are not playing with the human life but this is the truth and what that lawyer told me isn't incorrect. If what you say is different than what I explained here, then I encourage you to consult with a Patent specialist.

Smile,
Hosnieh

---

From: Christian Huitema <[email-masked]>
Date: Wed, 20 Nov 2013 20:37:16 +0000

> > > charity sake but if I am going to make money out of it, I have to 
> > > pay to the owner of the patent.
> > 
> > my observation is that most Internet-related products are not donated to charity.
> > 
> >     Brian
>

Hosnieh,

You should study this subject a little bit more. What matters is not whether a solution is patented or not, but rather what licensing conditions are imposed by the patent owner. This has been extensively debated in the IETF at many occasions. In your virus example, the patent owners are trying to license their invention for a fee, i.e. to extract royalties. But in the CGA example, we have two companies owning relevant IP that have both assured the IETF that they do not want a fee, either by promising a royalties free license, or by assuring that they will "not assert" their patent. So, no, these two companies are not going to extract revenues from application of their patents to CGA. 

-- Christian Huitema

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Nov 2013 21:53:03 +0100

<nohat>

as Christian pointed out there is a challenge with lack of SEND deployment.
I'm not under the impression that CGA is the reason for that(?)

will SSAS make SEND more deployable?
if the answer to that is no, then I'm not sure I would support spending the effort on this.
(working for a company that actually have implemented SEND).

cheers,
Ole

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 01:15:49 +0100

Hi Christian,

> Hosnieh,
> 
> You should study this subject a little bit more. What matters is not whether a
> solution is patented or not, but rather what licensing conditions are imposed
> by the patent owner. This has been extensively debated in the IETF at many
> occasions. In your virus example, the patent owners are trying to license their
> invention for a fee, i.e. to extract royalties. But in the CGA example, we have
> two companies owning relevant IP that have both assured the IETF that they
> do not want a fee, either by promising a royalties free license, or by assuring
> that they will "not assert" their patent. So, no, these two companies are not
> going to extract revenues from application of their patents to CGA.
> 
> -- Christian Huitema
> 

Sorry for my stupid questions. If it is royalty free even for selling it, why didn't Microsoft, itself, implement CGA? I guess Microsoft was one of the owner of this proposal. Isn't it because of unclear agreements of two patent's owners for its profit like what was happening in my example? 

Thanks,
Smile, 
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 01:32:53 +0100

Follow up,
Two companies I mean Ericson and Microsoft.
https://datatracker.ietf.org/ipr/490/
https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3972 

-----------smile----------
Hosnieh
… success is a journey, not a destination….
You cannot change your destination overnight, but you can change your direction ... Focus on the journey

> -----Original Message-----
> From: Hosnieh Rafiee [mailto:[email-masked]]
> Sent: Thursday, November 21, 2013 1:16 AM
> To: 'Christian Huitema'; 'Brian E Carpenter'
> Cc: '6man Chairs'; 'Erik Nordmark'; 'Tim Chown'; '6man WG'; 'Ray Hunter'
> Subject: RE: 6MAN Adoption call on draft-rafiee-6man-ssas-07
> 
> Hi Christian,
> 
> 
> > Hosnieh,
> >
> > You should study this subject a little bit more. What matters is not
> > whether a solution is patented or not, but rather what licensing
> > conditions are imposed by the patent owner. This has been extensively
> > debated in the IETF at many occasions. In your virus example, the
> > patent owners are trying to license their invention for a fee, i.e. to
> > extract royalties. But in the CGA example, we have two companies
> > owning relevant IP that have both assured the IETF that they do not
> > want a fee, either by promising a royalties free license, or by
> > assuring that they will "not assert" their patent. So, no, these two companies
> are not going to extract revenues from application of their patents to CGA.
> >
> > -- Christian Huitema
> >
> 
> Sorry for my stupid questions. If it is royalty free even for selling it, why didn't
> Microsoft, itself, implement CGA? I guess Microsoft was one of the owner of
> this proposal. Isn't it because of unclear agreements of two patent's owners
> for its profit like what was happening in my example?
> 
> Thanks,
> Smile,
> Hosnieh
>

---

From: Christian Huitema <[email-masked]>
Date: Thu, 21 Nov 2013 00:46:20 +0000

> Sorry for my stupid questions. If it is royalty free even for selling 
> it, why didn't Microsoft, itself, implement CGA? I guess Microsoft was 
> one of the owner of this proposal. Isn't it because of unclear 
> agreements of two patent's owners for its profit like what was happening in my example?

Microsoft chose to not implement CGA/SEND based on planning considerations and development priorities for the new versions of Windows. This really has nothing to do with patent considerations. It has a lot to do with the SEND scenario.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Thu, 21 Nov 2013 05:42:47 +0000

>   of it. It is royalty free for charity implementation.

The IPR statement from Microsoft relating to CGA specifies "Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers." There is 
no particular restriction against commercial applications. The IPR statement from Ericsson is a classic non-assert, which also does not discriminates against commercial implementation.

>  efficiently for other processes and programs in your computer?!

It is definitely a tradeoff between security and cost of generation. Without that tradeoff, you only get 59 bits of proof, or at most 64 if we get rid of the sec and u/g bits. By the way, "sec=1" does not require 3 hours; last time I checked, it took only a few seconds on my laptop.

> public key and not a part of that, I refer you to the draft.

I have indeed read the draft. The proof in the IID is exactly 64 bit long, which means the scheme can be attacked by an enumeration attack in 2^64 iterations. Moreover, since there is no hashing with any location variable input, the enumeration can be stored in a catalog, enabling subsequent attacks to succeed immediately.

-- Christian Huitema

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Nov 2013 08:01:01 +0100

> >  - CGA only added the complexity of address generator. Really, do you
> > wish to  wait for about 3 hours to years to generate an IP address?!
> > Or just busy  your CPU with a hope of IP address generation instead of
> > using it  efficiently for other processes and programs in your
computer?!
> 
> It is definitely a tradeoff between security and cost of generation.
Without
> that tradeoff, you only get 59 bits of proof, or at most 64 if we get rid
of the
> sec and u/g bits. By the way, "sec=1" does not require 3 hours; last time
I
> checked, it took only a few seconds on my laptop.

Yesterday I was reading http://www.ietf.org/proceedings/56/slides/send-2.pdf
slide 3 at the end. 
Bits u and g is the way to determine whether this is CGA node in the network
or it is not if you have a mixed network.

> I have indeed read the draft. The proof in the IID is exactly 64 bit long,
which
> means the scheme can be attacked by an enumeration attack in 2^64
> iterations. Moreover, since there is no hashing with any location variable
> input, the enumeration can be stored in a catalog, enabling subsequent
> attacks to succeed immediately.

The node keeps the public key of other nodes in their neighboring cache. You
have this opportunity only for a few seconds! So, when your node next time
verify the other nodes for reachability, the attacker needs to consider the
security of the whole public key. See here
http://www.ietf.org/proceedings/88/slides/slides-88-6man-11.pdf 

http://www.ietf.org/proceedings/87/slides/slides-87-6man-6.pdf both
proposals

Smile,
Hosnieh

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Nov 2013 08:32:03 +1300

On 21/11/2013 20:01, Hosnieh Rafiee wrote:
...
> or it is not if you have a mixed network.

To be precise, the slides say:

"CGA address indicated by g=1, u=1
(not essential but allows mixing of
authenticated and unauthenticated nodes)"

I really hope nobody has written code like

  if g==1 and u==1 then it's definitely a CGA;

because that is simply broken. I read the slide as saying
that using u=g=1 probably avoids IID collision. In any case
we have recently declared that those bits have no semantics.

   Brian