Hi Eric | -----Mensaje original----- | De: Eric Levy-Abegnoli [mailto:elevyabe at cisco.com] | Enviado el: lunes, 02 de noviembre de 2009 16:02 | Para: Alberto García | CC: 'Christian Vogt'; 'SAVI Mailing List' | Asunto: Re: [savi] A few comments on draft-vogt-savi-framework | | Alberto, | Alberto García a écrit : | > Hi | > | > | -----Mensaje original----- | > | De: savi-bounces at ietf.org [mailto:savi-bounces at ietf.org] En nombre de | > Eric | > | Levy-Abegnoli | > | Enviado el: lunes, 02 de noviembre de 2009 11:42 | > | Para: Christian Vogt | > | CC: SAVI Mailing List; Alberto García | > | Asunto: Re: [savi] A few comments on draft-vogt-savi-framework | > | | > | Christian, | > | Christian Vogt a écrit : | > | | > | Alberto - | > | | > | As a member of the working group, not as its chair: You are right | > | that co-existence scenarios need to be handled. But I'm not sure | > that | > | coexistence requires /special/ behavior. As long as the behavior | > | desired for coexistence scenarios does not preclude the behavior | > | desired for non-coexistence scenarios, I think coexistence should be | > | covered by the /regular/ behavior of the various SAVI protocol | > | specifications. That is, in the particular case of SLAAC/SEND co- | > | existence, I think we should strive for a SAVI SEND protocol that | > can | > | handle non-SEND-capable SAVI devices. | > | | > | | > | As we are centralizing the co-existence decisions in a | > "man-in-the-middle" savi- | > | device, we can't just consider that the capability of the savi-device | > (SeND, not | > | SeND) are it's sole problem. Which "looks" the case if the co-existence | > scenarios | > | are described in the savi-SeND protocol specification. | > | > I don't understand this. What's the problem with a situation in which the | > manager of the network configures SAVI devices... | > - in SLAAC-only mode if it knows no SEND hosts are there | > - in SEND-only mode if it knows all hosts are SEND | > - in SLAAC-SEND-compatible mode if it knows the network has SEND and no | SEND | > hosts. | > I assume that deploying SAVI is going to require some management (we have | > assumed that when stating that there are roles such as Trusted and | > Validating). For SEND even more configuration is required in the SAVI | > devices (i.e. trust anchors). | > | It is not realistic to expect that the operator will know **all** | end-nodes capabilities. There might be thousands of them, | (I know an enterprise which as 100,000) and they could show up or | disappear at n a very dynamic pace. | Also, there is an organisation issue; quite commonly, the network in | controlled by one entity, the end-nodes by a different one. | Security so far is mostly dealt with by end-nodes, not network | elements. If we move some security feature out of the end-nodes | into a network box, we must insure it does at least an equivalent job. In this case I assume that the SAVI devices should be SLAAC-SEND compatible (it is a case in which the operator assumes could be any of them). Is this a problem? | | For CGA, no provisionning (trust anchor) is required what-so-ever. So | the SAVI has no other way to know than to look at | the CGA option. I agree about that. However, I don't like very much talking about CGA, but about SEND. SEND specifies the behavior for validating host addresses (that must be CGAs), but also for validating router-related information (router identity and prefixes). For the last issue, trust anchors is the way defined in the RFC3971 to do this. Note that for SEND SAVI operation, it is relevant to be able to identify local traffic from transit traffic, and to do this, the devices must know which prefixes are on-link. A good dynamic way to do this is to use the signing facility for RADV info of SEND, whose validation depends on trust anchors. Otherwise, the operator must configure manually the prefixes... i.e. a lot of configuration in SAVI devices, which was the point here (configuration of the operation mode of SAVI devices is not an issue compared to the rest of the configuration required). | > SEND hosts also need to be configured with trust anchors for processing | > correctly secured RADV. (well, the manager may not know if two hosts | > configure CGAs just for communication among themselves, but, is this the | > general case? ) | > So, the manager will provide the appropriate SAVI operation mode. | > | We are talking about address assignment, right? Then CGA does not | require any centralized provisionning of any kind. | In particular no trust anchor. Yes, agreed | > In addition, the compatible mode should work fine for both types of hosts. A | > manager with SAVI devices capable of this, and with any suspicion that a | > SEND host may appear, may set up the SAVI devices to be in this mode. | > | > Do you think this deployment model for SAVI is reasonable? | > | There are many situations where he will not know. We (SeND) have | designed a distributed protocol where end-nodes can | take care of their own security. And now by centralizing some of the | security, we (SAVI) are breaking this model. | I think this is going to be a SeND (or at least CGA) killer. Once | someone have deployed a bunch of SAVI switches, it won't be possible | anymore to deploy SeND on any subset of end-devices. ... or just deploy from the beginning SLAAC-SEND savi compatible devices. Well, I'm not seriously proposing this (due to cost considerations). But I'm not so pessimistic as you are: SLAAC SAVI provides to SLAAC more security than SEND. Even SLAAC SAVI for SEND provides a different type of security, that is applied to data packets (SEND only protects the binding between IP address and layer-2 address), which is an additional security that does not exist now for SEND operation. For SLAAC SAVI, when a host receives SEND ND messages, it knows that the additional protection for the IP / layer 2 address binding is there. Agreed that does not provide priority to SEND hosts (which occurs in RFC3971), and does not protect DAD for unsecured NADV in 2nd and 3rd times. Which I assume that would make users ask their operators to change SAVI devices to SEND-compatible ones. By the way, I think some kind of notification (such as the ICMP message currently suggested to generate when discarding packets) would enable, at least, some kind of feedback specially relevant for SEND hosts (or users of the host). Alberto | Eric | > | A savi device not SEND-capable breaks RFC3971. | > Yes, so when a SEND host exists, SAVI must be SEND enabled. | > | > | Like a bridge that would mess | > | with L3 messages. And it has no way to know. | > | > This is where I kindly disagree. | > Regards, | > Alberto | > | > | Can we **really** specify that? | > | There might be thousands of non-SeND capable nodes on the link, and just | > one | > | signle pair of SeND nodes, and this SAVI-switch in the middle is | > completely | > | messing with their "standard" behavior. Note that there **are** such | > | deployments out there. And the deployments scenarios are exactly that | > (few | > | SeND critical nodes, many non-SeND). | > | So I think the description of this scenario, and associated warnings | > should show | > | up either in all documents, or in a higher level doc( framework, or | > other). | > | Eric | > | | > | | > | Does this make sense? | > | | > | - Christian | > | | > | | > | | > | On Oct 29, 2009, at 3:04, Alberto García wrote: | > | | > | | > | | > | My opinion is that priorization is not enough. | > | I think we need to define "operation modes" (SEND-only, | > SLAAC- | > | only, | > | SEND-SLAAC-compatible...) and describe the state machine for | > | each one. | > | | > | To support the idea of why we need a new state machine for | > | SEND-SLAAC | > | compatibility, i.e. for a domain in which both SEND hosts | > and | > | non- | > | SEND hosts | > | coexist, just consider what a node should do (extending | > naturally | > | the | > | current FCFS and SEND proposals) if a SAVI device is in | > | NO_BIND | > | state, and a | > | data packet (not DAD NSOL) is received, from a Validating | > port | > | VP. | > | In this | > | case, the SEND SAVI device should send | > | - 2 (unsecured) NSOL messages through Trusted ports | > | (according to | > | FCFS SAVI) | > | - and a secured NUD NSOL message through the | > | Validating Port | > | (according to SEND SAVI | > | And The state is moved to TENTATIVE. | > | | > | In the TENTATIVE state, the SAVI device should maybe wait | > long | > | enough (a | > | RetransTimer, which is the waiting time for NUD operation) | > for a | > | secured NUD | > | NADV even if an unsecured DAD NSOL is received from a | > trusted | > | port | > | in the | > | meanwhile, to assure that SEND validated addresses have | > priority | > | over | > | non-SEND addresses. [Note that this may occur if a SEND host | > | has one | > | collision when performing DAD for an address, and it is not | > | withdrawing the | > | second address if an unsecured DAD NSOL is received for it, | > as | > | RFC | > | 3971 | > | says]. | > | Different states should be defined (VALID_SEND, | > | VALID_NON_SEND), with | > | different behavior when the valid_timeout expires. | > | | > | | > | So I don't think this is just "ships in the night", but | > different | > | modes | > | should be defined to integrate all the possible combinations | > of | > | address | > | configuration mechanisms. Maybe one of these modes should be | > | the | > | default | > | one, but the administrator could set the SAVI devices to the | > | appropriate | > | mode (well, they also have to define which ports are trusted | > or | > | not...). | > | | > | Does this make sense? | > | Regards, | > | Alberto | > | | > | | > | | > | | > | | > | _______________________________________________ | > | savi mailing list | > | savi at ietf.org | > | https://www.ietf.org/mailman/listinfo/savi | > | | > | | > | | > | > | > | >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.