Subject: [savi] Comments to draft-ietf-savi-framework-00

From: Alberto García <[email-masked]>
Date: Wed, 20 Oct 2010 15:11:06 +0200

Hi,

After reading the savi-framework document, I have some comments:

-        I think the case in which address configuration is being done
manually is not covered appropriately by the framework. First, it should
appear in the 'IP address assignment method' section. Besides, some kind of
mechanism definition should be specified for manual address configuration
which would suit to the "protection perimeter" model. The model should
include rules such as 'discard everything coming from a Validating port
unless a manually created binding exist', 'accept everything coming from a
Trusted port'. Maybe this could suit into the framework document, although
maybe it would require more than Informational 'intended status'. 

(side comment: when interaction between different address configuration
mechanisms were to be addressed, manually configured addresses should also
be taken into account, since the SAVI device should defend the manual
configuration somehow - for example, when a host connected to another SAVI
device tries to use SLAAC to configure the same address).

-        In section 4, when talking about the 'protection perimeter', I
think some considerations about the security risks of changes in the
topology of the switches should be stated. In section 5 (Reliability
Optimizations), it is stated that legitimate packets can be lost if the link
topology changes, but the problem is even harder: some resulting topologies
could be intrinsically non-defendable, for example, if the perimeter is
breached by a topology change. This is common to all SAVI solutions, so I
think this comment should be in the framework document.

-        There is also one concept that should appear anywhere in the
document (maybe section 5): SAVI solutions are defined in general to support
host mobility (in the sense of hosts that change their attaching points from
one layer-2 anchor to a different one - such as changing the port of
attachment). This is a nice feature provided by SAVI that should be
presented. 

Finally, one nit: in ref [BA2007],            

s/Fred, F./Baker, F.

Besides, I think the document is well-written and provides useful
information.

Regards,

Alberto

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 20 Oct 2010 21:38:18 +0800

From: Alberto García 
Sent: Wednesday, October 20, 2010 9:11 PM
To: [email-masked] 
Subject: [savi] Comments to draft-ietf-savi-framework-00

Hi,

-        I think the case in which address configuration is being done manually is not covered appropriately by the framework. First, it should appear in the 'IP address assignment method' section. Besides, some kind of mechanism definition should be specified for manual address configuration which would suit to the "protection perimeter" model. The model should include rules such as 'discard everything coming from a Validating port unless a manually created binding exist', 'accept everything coming from a Trusted port'. Maybe this could suit into the framework document, although maybe it would require more than Informational 'intended status'. 

(side comment: when interaction between different address configuration mechanisms were to be addressed, manually configured addresses should also be taken into account, since the SAVI device should defend the manual configuration somehow - for example, when a host connected to another SAVI device tries to use SLAAC to configure the same address).

       junbi:  thanks  to the comment. 

                 I think for SAVI IPv6, user manually configured address = SLAAC. 

                 For SAVI IPv4, draft-bi-stateless-01 (attached)  described the solution for IPv4 manually configured address by snooping ARP packets.

                 I propose Marcelo to merge this part of draft-bi-stateless-01 into the SAVI SLAAC solution draft.

                 Thanks,

-        In section 4, when talking about the 'protection perimeter', I think some considerations about the security risks of changes in the topology of the switches should be stated. In section 5 (Reliability Optimizations), it is stated that legitimate packets can be lost if the link topology changes, but the problem is even harder: some resulting topologies could be intrinsically non-defendable, for example, if the perimeter is breached by a topology change. This is common to all SAVI solutions, so I think this comment should be in the framework document.

-        There is also one concept that should appear anywhere in the document (maybe section 5): SAVI solutions are defined in general to support host mobility (in the sense of hosts that change their attaching points from one layer-2 anchor to a different one - such as changing the port of attachment). This is a nice feature provided by SAVI that should be presented. 

             junbi:  yes, L2 mobility is the scope in SAVI charter.

s/Fred, F./Baker, F.

Besides, I think the document is well-written and provides useful information.

Regards,

Alberto

--------------------------------------------------------------------------------

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 20 Oct 2010 15:50:45 +0200

I understand Alberto is talking about manually configured bindings in 
the SAVI device, which seems one possible way to support manually 
configured addresses.
I think the first question to ask to the WG is whether we think we need 
to support manually configured bindings in the SAVI devices. If yes, 
then we need to provide guidelines of how to configure the ports, 
whether the binding need to be configured in all the devices of the 
perimter or only in one and so on.
I believe this should be a couple of paragrpahs, and if that is the 
case, including this in the framework document seems a good place to put it.

The point you raise, is whether we should include ARP snooping based 
configuration for IPv4 addresses. This was initially included in the 
FCFS document and it was dropped because the WG thought it was a bad 
idea. The main reason for that is that given that the IPv4 address space 
allocated to a IPv4 subnet is small (in the order of hundres of 
addresses) it would be fairly easy for an attacker to perform a DoS 
attakc and create bindings for all the addresses in a given subnetwork, 
and not allowing any other host to access to an address.

Regards, marcelo

El 20/10/10 15:38, Jun Bi escribió:
>
> *From:* Alberto García <mailto:[email-masked]>
> *Sent:* Wednesday, October 20, 2010 9:11 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [savi] Comments to draft-ietf-savi-framework-00
>
> Hi,
>
> manually is not covered appropriately by the framework. First, it 
> should appear in the ‘IP address assignment method’ section. Besides, 
> some kind of mechanism definition should be specified for manual 
> address configuration which would suit to the “protection perimeter” 
> model. The model should include rules such as ‘discard everything 
> coming from a Validating port unless a manually created binding 
> exist’, ‘accept everything coming from a Trusted port’. Maybe this 
> could suit into the framework document, although maybe it would 
> require more than Informational ‘intended status’.
>
> (side comment: when interaction between different address 
> configuration mechanisms were to be addressed, manually configured 
> addresses should also be taken into account, since the SAVI device 
> should defend the manual configuration somehow – for example, when a 
> host connected to another SAVI device tries to use SLAAC to configure 
> the same address).
>
> For SAVI IPv4, draft-bi-stateless-01 (attached) described the solution 
> for IPv4 manually configured address by snooping ARP packets.
>
> - In section 4, when talking about the ‘protection perimeter’, I think 
> some considerations about the security risks of changes in the 
> Optimizations), it is stated that legitimate packets can be lost if 
> the link topology changes, but the problem is even harder: some 
> resulting topologies could be intrinsically non-defendable, for 
> example, if the perimeter is breached by a topology change. This is 
> common to all SAVI solutions, so I think this comment should be in the 
> framework document.
>
> document (maybe section 5): SAVI solutions are defined in general to 
> support host mobility (in the sense of hosts that change their 
> attaching points from one layer-2 anchor to a different one – such as 
> changing the port of attachment). This is a nice feature provided by 
> SAVI that should be presented.
>
> ------------------------------------------------------------------------

---

From: Alberto García <[email-masked]>
Date: Wed, 20 Oct 2010 16:21:56 +0200

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
marcelo
|  bagnulo braun
|  Enviado el: miércoles, 20 de octubre de 2010 15:51
|  Para: [email-masked]
|  Asunto: Re: [savi] Comments to draft-ietf-savi-framework-00
|  
|    I understand Alberto is talking about manually configured bindings in
|  the SAVI device, which seems one possible way to support manually
|  configured addresses.

Yes.

Regards,
Alberto

|  I think the first question to ask to the WG is whether we think we need
|  to support manually configured bindings in the SAVI devices. If yes,
|  then we need to provide guidelines of how to configure the ports,
|  whether the binding need to be configured in all the devices of the
|  perimter or only in one and so on.
|  I believe this should be a couple of paragrpahs, and if that is the
|  case, including this in the framework document seems a good place to put
it.
|  
|  The point you raise, is whether we should include ARP snooping based
|  configuration for IPv4 addresses. This was initially included in the
|  FCFS document and it was dropped because the WG thought it was a bad
|  idea. The main reason for that is that given that the IPv4 address space
|  allocated to a IPv4 subnet is small (in the order of hundres of
|  addresses) it would be fairly easy for an attacker to perform a DoS
|  attakc and create bindings for all the addresses in a given subnetwork,
|  and not allowing any other host to access to an address.
|  
|  Regards, marcelo
|  
|  
|  El 20/10/10 15:38, Jun Bi escribió:
|  >
|  > *From:* Alberto García <mailto:[email-masked]>
|  > *Sent:* Wednesday, October 20, 2010 9:11 PM
|  > *To:* [email-masked] <mailto:[email-masked]>
|  > *Subject:* [savi] Comments to draft-ietf-savi-framework-00
|  >
|  > Hi,
|  >
|  > After reading the savi-framework document, I have some comments:
|  >
|  > - I think the case in which address configuration is being done
|  > manually is not covered appropriately by the framework. First, it
|  > should appear in the 'IP address assignment method' section. Besides,
|  > some kind of mechanism definition should be specified for manual
|  > address configuration which would suit to the "protection perimeter"
|  > model. The model should include rules such as 'discard everything
|  > coming from a Validating port unless a manually created binding
|  > exist', 'accept everything coming from a Trusted port'. Maybe this
|  > could suit into the framework document, although maybe it would
|  > require more than Informational 'intended status'.
|  >
|  > (side comment: when interaction between different address
|  > configuration mechanisms were to be addressed, manually configured
|  > addresses should also be taken into account, since the SAVI device
|  > should defend the manual configuration somehow - for example, when a
|  > host connected to another SAVI device tries to use SLAAC to configure
|  > the same address).
|  >
|  > junbi: thanks to the comment.
|  >
|  > I think for SAVI IPv6, user manually configured address = SLAAC.
|  >
|  > For SAVI IPv4, draft-bi-stateless-01 (attached) described the solution
|  > for IPv4 manually configured address by snooping ARP packets.
|  >
|  > I propose Marcelo to merge this part of draft-bi-stateless-01 into the
|  > SAVI SLAAC solution draft.
|  >
|  > Thanks,
|  >
|  > - In section 4, when talking about the 'protection perimeter', I think
|  > some considerations about the security risks of changes in the
|  > topology of the switches should be stated. In section 5 (Reliability
|  > Optimizations), it is stated that legitimate packets can be lost if
|  > the link topology changes, but the problem is even harder: some
|  > resulting topologies could be intrinsically non-defendable, for
|  > example, if the perimeter is breached by a topology change. This is
|  > common to all SAVI solutions, so I think this comment should be in the
|  > framework document.
|  >
|  > - There is also one concept that should appear anywhere in the
|  > document (maybe section 5): SAVI solutions are defined in general to
|  > support host mobility (in the sense of hosts that change their
|  > attaching points from one layer-2 anchor to a different one - such as
|  > changing the port of attachment). This is a nice feature provided by
|  > SAVI that should be presented.
|  >
|  > junbi: yes, L2 mobility is the scope in SAVI charter.
|  >
|  > Finally, one nit: in ref [BA2007],
|  >
|  > s/Fred, F./Baker, F.
|  >
|  > Besides, I think the document is well-written and provides useful
|  > information.
|  >
|  > Regards,
|  >
|  > Alberto
|  >
|  >
------------------------------------------------------------------------
|  > _______________________________________________
|  > savi mailing list
|  > [email-masked]
|  > https://www.ietf.org/mailman/listinfo/savi
|  >
|  >
|  > _______________________________________________
|  > savi mailing list
|  > [email-masked]
|  > https://www.ietf.org/mailman/listinfo/savi
|  
|  _______________________________________________
|  savi mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi

---

From: "Bi Jun" <[email-masked]>
Date: Wed, 20 Oct 2010 22:28:04 +0800

Hi, Marcelo,

Let me have more sentences on it. At operation terms in our campus network, 
usually, "manual address" means "user manually configured address at its 
host", not "static address" (which is assigned by administrator by off-line 
registration and manually configured at switch by administrator).

For static address, it's just the configure SAVI-switch ports and a couple 
of paragraph in SAVI-framework.

For manual address, I think it equals stateless (in IPv6 and IPv4).No matter 
in IPv6 or IPv4, we should handle DoS attack on address exhausting. One of 
possible way to handle it is discussed in section 20 Binding Number 
Limitation in draft-bi-stateless-01.

thanks,
Jun Bi

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Wednesday, October 20, 2010 9:50 PM
To: <[email-masked]>
Subject: Re: [savi] Comments to draft-ietf-savi-framework-00

>  I understand Alberto is talking about manually configured bindings in the 
> SAVI device, which seems one possible way to support manually configured 
> addresses.
> I think the first question to ask to the WG is whether we think we need to 
> support manually configured bindings in the SAVI devices. If yes, then we 
> need to provide guidelines of how to configure the ports, whether the 
> binding need to be configured in all the devices of the perimter or only 
> in one and so on.
> I believe this should be a couple of paragrpahs, and if that is the case, 
> including this in the framework document seems a good place to put it.
>
> configuration for IPv4 addresses. This was initially included in the FCFS 
> document and it was dropped because the WG thought it was a bad idea. The 
> main reason for that is that given that the IPv4 address space allocated 
> to a IPv4 subnet is small (in the order of hundres of addresses) it would 
> be fairly easy for an attacker to perform a DoS attakc and create bindings 
> for all the addresses in a given subnetwork, and not allowing any other 
> host to access to an address.
>
> Regards, marcelo
>
>
>> - I think the case in which address configuration is being done manually 
>> is not covered appropriately by the framework. First, it should appear in 
>> the ‘IP address assignment method’ section. Besides, some kind of 
>> which would suit to the “protection perimeter” model. The model should 
>> include rules such as ‘discard everything coming from a Validating port 
>> unless a manually created binding exist’, ‘accept everything coming 
>> from a Trusted port’. Maybe this could suit into the framework document, 
>> although maybe it would require more than Informational ‘intended status’.
>>
>> mechanisms were to be addressed, manually configured addresses should 
>> also be taken into account, since the SAVI device should defend the 
>> manual configuration somehow – for example, when a host connected to 
>> another SAVI device tries to use SLAAC to configure the same address).
>>
>> some considerations about the security risks of changes in the topology 
>> of the switches should be stated. In section 5 (Reliability 
>> Optimizations), it is stated that legitimate packets can be lost if the 
>> link topology changes, but the problem is even harder: some resulting 
>> topologies could be intrinsically non-defendable, for example, if the 
>> perimeter is breached by a topology change. This is common to all SAVI 
>> solutions, so I think this comment should be in the framework document.
>>
>> - There is also one concept that should appear anywhere in the document 
>> (maybe section 5): SAVI solutions are defined in general to support host 
>> mobility (in the sense of hosts that change their attaching points from 
>> one layer-2 anchor to a different one – such as changing the port of

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 20 Oct 2010 16:30:39 +0200

El 20/10/10 16:28, Bi Jun escribió:
> Hi, Marcelo,
>
> Let me have more sentences on it. At operation terms in our campus 
> network, usually, "manual address" means "user manually configured 
> address at its host", not "static address" (which is assigned by 
> administrator by off-line registration and manually configured at 
> switch by administrator).
>
makes sense

> For static address, it's just the configure SAVI-switch ports and a 
> couple of paragraph in SAVI-framework.

ok
>
> For manual address, I think it equals stateless (in IPv6 and IPv4).No 
> matter in IPv6 or IPv4, we should handle DoS attack on address exhausting.

mmm, how is it possible for an attacker to exhaust 2^64 addresses which 
is the default addresses in an IPv6 sublink?

Regards, marcelo

> One of possible way to handle it is discussed in section 20 Binding 
> Number Limitation in draft-bi-stateless-01.
>
> thanks,
> Jun Bi
>
>
>>  I understand Alberto is talking about manually configured bindings 
>> in the SAVI device, which seems one possible way to support manually 
>> configured addresses.
>> I think the first question to ask to the WG is whether we think we 
>> need to support manually configured bindings in the SAVI devices. If 
>> yes, then we need to provide guidelines of how to configure the 
>> ports, whether the binding need to be configured in all the devices 
>> of the perimter or only in one and so on.
>> idea. The main reason for that is that given that the IPv4 address 
>> space allocated to a IPv4 subnet is small (in the order of hundres of 
>> attakc and create bindings for all the addresses in a given 
>> subnetwork, and not allowing any other host to access to an address.
>>
>> Regards, marcelo
>>
>>
>>> should appear in the ‘IP address assignment method’ section. 
>>> Besides, some kind of mechanism definition should be specified for 
>>> manual address configuration which would suit to the “protection 
>>> perimeter” model. The model should include rules such as ‘discard 
>>> everything coming from a Validating port unless a manually created 
>>> binding exist’, ‘accept everything coming from a Trusted port’. 
>>> Maybe this could suit into the framework document, although maybe it 
>>> would require more than Informational ‘intended status’.
>>>
>>> host connected to another SAVI device tries to use SLAAC to 
>>> configure the same address).
>>>
>>> For SAVI IPv4, draft-bi-stateless-01 (attached) described the 
>>> solution for IPv4 manually configured address by snooping ARP packets.
>>>
>>> - In section 4, when talking about the ‘protection perimeter’, I 
>>> common to all SAVI solutions, so I think this comment should be in 
>>> the framework document.
>>>
>>> attaching points from one layer-2 anchor to a different one – such 
>>> as changing the port of attachment). This is a nice feature provided 
>>> by SAVI that should be presented.
>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 20 Oct 2010 16:32:59 +0200

> switch by administrator).

sorry, i thought i understood this, but now i am not sure.
So, in the manual address case, where does the user obtains the address 
from? It is not assigned by off line admin?

Regards, marcelo

> matter in IPv6 or IPv4, we should handle DoS attack on address 
> exhausting. One of possible way to handle it is discussed in section 
> 20 Binding Number Limitation in draft-bi-stateless-01.
>
> thanks,
> Jun Bi
>
>

---

From: "Guang Yao" <[email-masked]>
Date: Wed, 20 Oct 2010 22:34:43 +0800

For the first point, IMO it is important to keep the uniqueness of manually configured address on the whole perimeter. But it brings too much management overhead to configure corresponding rule on each SAVI device. I suggest, 1) SAVI device should hold the address through performing ND proxy for all local manually configured addresses; 2) the manually configured addresses must be excluded from the DHCP address pool. Then the address wouldn't be bound on other devices.

For the second point, I think there still should be some mechanism to handle the scenario that all IPv4 addresses are configured by clients manually, otherwise this situation is not covered by any SAVI solution. To mitigate the DoS against the address pool, the binding number limitation on each binding anchor can be set.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> marcelo bagnulo braun
> Sent: Wednesday, October 20, 2010 9:51 PM
> To: [email-masked]
> support manually configured bindings in the SAVI devices. If yes, then we need
> to provide guidelines of how to configure the ports, whether the binding need
> to be configured in all the devices of the perimter or only in one and so on.
> I believe this should be a couple of paragrpahs, and if that is the case, including
> this in the framework document seems a good place to put it.
> 
> main reason for that is that given that the IPv4 address space allocated to a
> IPv4 subnet is small (in the order of hundres of
> addresses) it would be fairly easy for an attacker to perform a DoS attakc and
> create bindings for all the addresses in a given subnetwork, and not allowing
> any other host to access to an address.
> 
> Regards, marcelo
> 
> 
> > ----------------------------------------------------------------------
> > -- _______________________________________________
> > savi mailing list
> > [email-masked]

---

From: "Guang Yao" <[email-masked]>
Date: Wed, 20 Oct 2010 22:45:36 +0800

A real case in Tsinghua: we know the /24 prefix, and we want relatively fixed address scope whenever we attached our computers, thus we don't rely on the DHCP server. Instead, we begin with trying the address used yesterday, and then the address++ and so on until a free address is found.

Best regards,
Guang

> Sent: Wednesday, October 20, 2010 10:33 PM
> To: Bi Jun
> Cc: [email-masked]
> So, in the manual address case, where does the user obtains the address from?
> It is not assigned by off line admin?
> 
> Regards, marcelo
> 
> >

---

From: "Bi Jun" <[email-masked]>
Date: Wed, 20 Oct 2010 22:54:11 +0800

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Wednesday, October 20, 2010 10:32 PM
To: "Bi Jun" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [savi] Comments to draft-ietf-savi-framework-00

>> administrator by off-line registration and manually configured at switch 
>> by administrator).
>

User just pick one address by himself (that why I said it is like 
"stateless"). In the realty world, students do it very often, then the 
manual address conflicts with other mannual addresses or dhcpv4 assigned 
address very often.
So I hope savi should resolve it.

thanks,
Jun Bi

>> exhausting. One of possible way to handle it is discussed in section 20 
>> Binding Number Limitation in draft-bi-stateless-01.
>>
>> thanks,
>> Jun Bi
>>
>>
>>>> coming from a Validating port unless a manually created binding exist’, 
>>>> ‘accept everything coming from a Trusted port’. Maybe this could suit 
>>>> into the framework document, although maybe it would require more than 
>>>> Informational ‘intended status’.
>>>>
>>>> (maybe section 5): SAVI solutions are defined in general to support 
>>>> host mobility (in the sense of hosts that change their attaching points 
>>>> from one layer-2 anchor to a different one – such as changing the port 
>>>> of attachment). This is a nice feature provided by SAVI that should be 
>>>> presented.
>>>>

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 20 Oct 2010 22:58:39 +0800

Sent: Wednesday, October 20, 2010 10:30 PM

>> exhausting.
> mmm, how is it possible for an attacker to exhaust 2^64 addresses which is 
> the default addresses in an IPv6 sublink?

Dear Marcelo,

Do you really think a savi-switch can support 2^64 savi binding entries?
At CNGI savi deployment, we tested that current vendors support several 
hundreds entries at one savi switch. It's very easy for an attacker to 
exhaust these entries if there is no protection.

thanks,
Jun Bi

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 20 Oct 2010 23:01:38 +0800

--------------------------------------------------
From: "Bi Jun" <[email-masked]>
Sent: Wednesday, October 20, 2010 10:54 PM
To: "marcelo bagnulo braun" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [savi] Comments to draft-ietf-savi-framework-00

By the way, the current windows/unix OS allow user to manually configure any 
address
in the right prefix, so it's very easy.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 20 Oct 2010 17:06:38 +0200

El 20/10/10 16:58, Jun Bi escribió:
>>> For manual address, I think it equals stateless (in IPv6 and 
>>> IPv4).No matter in IPv6 or IPv4, we should handle DoS attack on 
>>> address exhausting.
>>
>> mmm, how is it possible for an attacker to exhaust 2^64 addresses 
>> which is the default addresses in an IPv6 sublink?
>
>
> Dear Marcelo,
>

sure, but that is a DoS attack to the memory of the SAVI device and not 
to the address space available to the subnet

I do believe a savi switch can support 2^8 entries, and a /24 is a 
common value for v4 subnets

Regards, marcelo

> At CNGI savi deployment, we tested that current vendors support 
> several hundreds entries at one savi switch. It's very easy for an 
> attacker to exhaust these entries if there is no protection.
>
> thanks,
> Jun Bi
>
>
>
>
>
>
>>
>> Regards, marcelo
>>
>>
>>>> in the SAVI device, which seems one possible way to support 
>>>> manually configured addresses.
>>>> need to support manually configured bindings in the SAVI devices. 
>>>> If yes, then we need to provide guidelines of how to configure the 
>>>> The point you raise, is whether we should include ARP snooping 
>>>> based configuration for IPv4 addresses. This was initially included 
>>>> in the FCFS document and it was dropped because the WG thought it 
>>>> was a bad idea. The main reason for that is that given that the 
>>>> IPv4 address space allocated to a IPv4 subnet is small (in the 
>>>> order of hundres of addresses) it would be fairly easy for an 
>>>> attacker to perform a DoS attakc and create bindings for all the 
>>>> addresses in a given subnetwork, and not allowing any other host to 
>>>> access to an address.
>>>>
>>>> Regards, marcelo
>>>>
>>>>
>>>>> Maybe this could suit into the framework document, although maybe 
>>>>> it would require more than Informational ‘intended status’.
>>>>>
>>>>> should defend the manual configuration somehow – for example, when 
>>>>> a host connected to another SAVI device tries to use SLAAC to 
>>>>> think some considerations about the security risks of changes in 
>>>>> the topology of the switches should be stated. In section 5 
>>>>> (Reliability Optimizations), it is stated that legitimate packets 
>>>>> can be lost if the link topology changes, but the problem is even 
>>>>> harder: some resulting topologies could be intrinsically 
>>>>> non-defendable, for example, if the perimeter is breached by a 
>>>>> topology change. This is common to all SAVI solutions, so I think 
>>>>> this comment should be in the framework document.
>>>>>
>>>>> document (maybe section 5): SAVI solutions are defined in general 
>>>>> to support host mobility (in the sense of hosts that change their 
>>>>> as changing the port of attachment). This is a nice feature 
>>>>> provided by SAVI that should be presented.
>>>>>

---

From: "Bi Jun" <[email-masked]>
Date: Wed, 20 Oct 2010 23:14:44 +0800

--------------------------------------------------
From: "marcelo bagnulo braun" <[email-masked]>
Sent: Wednesday, October 20, 2010 11:06 PM
To: "Jun Bi" <[email-masked]>
Cc: "Bi Jun" <[email-masked]>; <[email-masked]>
Subject: Re: [savi] Comments to draft-ietf-savi-framework-00

> sure, but that is a DoS attack to the memory of the SAVI device and not to 
> the address space available to the subnet
>

Hi Marcelo,

Under savi, when an attacker wants to DoS the subnet, it will also exhaust 
binding entry's SAVI at the same time. Then I think it's same affection on 
DoS subnet or memory. The limitation is not the maximum number of subnet 
size and memory size (where IPv6 case is quit different than IPv4 case at 
order of magnitudes), the limitation is actual the minimal number of subnet 
size and memory size (where IP6 case is not quit different with IPv4 case at 
order of magnitudes). That's what I meant in last email.

Jun

> I do believe a savi switch can support 2^8 entries, and a /24 is a common 
> value for v4 subnets
>
> Regards, marcelo
>
>
>>>>> yes, then we need to provide guidelines of how to configure the ports,

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 20 Oct 2010 17:20:15 +0200

El 20/10/10 17:14, Bi Jun escribió:
>>>>> For static address, it's just the configure SAVI-switch ports and 
>>>>> a couple of paragraph in SAVI-framework.
>>>>
>>>> ok
>>>>>
>> sure, but that is a DoS attack to the memory of the SAVI device and 
>> not to the address space available to the subnet
>>
>
> Hi Marcelo,
>
> Under savi, when an attacker wants to DoS the subnet, it will also 
> exhaust binding entry's SAVI at the same time. Then I think it's same 
> affection on DoS subnet or memory. The limitation is not the maximum 
> number of subnet size and memory size (where IPv6 case is quit 
> different than IPv4 case at order of magnitudes), the limitation is 
> actual the minimal number of subnet size and memory size (where IP6 
> case is not quit different with IPv4 case at order of magnitudes). 
> That's what I meant in last email.
>
I fail to understand your point.
could you expand?

>>>>> One of possible way to handle it is discussed in section 20 
>>>>>>  I understand Alberto is talking about manually configured 
>>>>>> bindings in the SAVI device, which seems one possible way to 
>>>>>> support manually configured addresses.
>>>>>> I think the first question to ask to the WG is whether we think 
>>>>>> we need to support manually configured bindings in the SAVI 
>>>>>> devices. If yes, then we need to provide guidelines of how to 
>>>>>> configure the ports, whether the binding need to be configured in 
>>>>>> all the devices of the perimter or only in one and so on.
>>>>>> I believe this should be a couple of paragrpahs, and if that is 
>>>>>> the case, including this in the framework document seems a good 
>>>>>> place to put it.
>>>>>>
>>>>>> based configuration for IPv4 addresses. This was initially 
>>>>>> included in the FCFS document and it was dropped because the WG 
>>>>>> thought it was a bad idea. The main reason for that is that given 
>>>>>> that the IPv4 address space allocated to a IPv4 subnet is small 
>>>>>> (in the order of hundres of addresses) it would be fairly easy 
>>>>>> for an attacker to perform a DoS attakc and create bindings for 
>>>>>> all the addresses in a given subnetwork, and not allowing any 
>>>>>> other host to access to an address.
>>>>>>
>>>>>> Regards, marcelo
>>>>>>
>>>>>>
>>>>>>> manually is not covered appropriately by the framework. First, 
>>>>>>> it should appear in the ‘IP address assignment method’ section. 
>>>>>>> Besides, some kind of mechanism definition should be specified 
>>>>>>> for manual address configuration which would suit to the 
>>>>>>> “protection perimeter” model. The model should include rules 
>>>>>>> such as ‘discard everything coming from a Validating port unless 
>>>>>>> a manually created binding exist’, ‘accept everything coming 
>>>>>>> from a Trusted port’. Maybe this could suit into the framework 
>>>>>>> document, although maybe it would require more than 
>>>>>>> configuration mechanisms were to be addressed, manually 
>>>>>>> configured addresses should also be taken into account, since 
>>>>>>> the SAVI device should defend the manual configuration somehow – 
>>>>>>> for example, when a host connected to another SAVI device tries 
>>>>>>> to use SLAAC to configure the same address).
>>>>>>>
>>>>>>> (Reliability Optimizations), it is stated that legitimate 
>>>>>>> packets can be lost if the link topology changes, but the 
>>>>>>> problem is even harder: some resulting topologies could be 
>>>>>>> intrinsically non-defendable, for example, if the perimeter is 
>>>>>>> breached by a topology change. This is common to all SAVI 
>>>>>>> document (maybe section 5): SAVI solutions are defined in 
>>>>>>> general to support host mobility (in the sense of hosts that 
>>>>>>> change their attaching points from one layer-2 anchor to a 
>>>>>>> different one – such as changing the port of attachment). This 
>>>>>>> is a nice feature provided by SAVI that should be presented.
>>>>>>>

---

From: "Guang Yao" <[email-masked]>
Date: Wed, 20 Oct 2010 23:20:45 +0800

> Sent: Wednesday, October 20, 2010 11:07 PM
> To: Jun Bi
> Cc: [email-masked]
> sure, but that is a DoS attack to the memory of the SAVI device and not to the
> address space available to the subnet
> 
> I do believe a savi switch can support 2^8 entries, and a /24 is a common value
> for v4 subnets
> 
> Regards, marcelo
> 
[Guang Yao] 
Just to ensure the fairness of address resource allocation/reservation is enough. It doesn't matter whether the resource is exhausted or not.

---

From: Alberto García <[email-masked]>
Date: Wed, 20 Oct 2010 17:23:26 +0200

Hi,
Just to clarify my comment: I was referring to bindings of an address and a
layer-2 anchor (port) which are created statically (manually) in the SAVI
device, and not as a result of interaction between the host and the SAVI
device.
I really don't care how these addresses are being configured in the host
(maybe manually, or resulting from EUI-64 address configuration which the
administrator knows in advance because it knows the MAC address of the nic,
etc.).

For this case, I suppose that no other port (either in this or in other SAVI
device) should ever have a binding for this address, so it should be
defended against other mechanisms trying to create a binding for this
address.
The port for which the static configuration is created should allow other
addresses to be configured by other mechanisms.

I assume that this is part of the service provided by Cisco's Safe Guard
(although I assume this product does not consider multiple filtering
devices, a perimetric deployment model...), and also does not consider
interaction with SLAAC...

Therefore, I think the case of the students you comment, Jun, is a different
one (SLAAC for IPv6).

Regards,
Alberto

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de Bi
Jun
|  Enviado el: miércoles, 20 de octubre de 2010 16:54
|  Para: marcelo bagnulo braun
|  CC: [email-masked]
|  Asunto: Re: [savi] Comments to draft-ietf-savi-framework-00
|  
|  
|  
|  --------------------------------------------------
|  From: "marcelo bagnulo braun" <[email-masked]>
|  Sent: Wednesday, October 20, 2010 10:32 PM
|  To: "Bi Jun" <[email-masked]>
|  Cc: <[email-masked]>
|  Subject: Re: [savi] Comments to draft-ietf-savi-framework-00
|  
|  >  El 20/10/10 16:28, Bi Jun escribió:
|  >> Hi, Marcelo,
|  >>
|  >> Let me have more sentences on it. At operation terms in our campus
|  >> network, usually, "manual address" means "user manually configured
|  >> address at its host", not "static address" (which is assigned by
|  >> administrator by off-line registration and manually configured at
switch
|  >> by administrator).
|  >
|  > sorry, i thought i understood this, but now i am not sure.
|  > So, in the manual address case, where does the user obtains the address
|  > from? It is not assigned by off line admin?
|  
|  User just pick one address by himself (that why I said it is like
|  "stateless"). In the realty world, students do it very often, then the
|  manual address conflicts with other mannual addresses or dhcpv4 assigned
|  address very often.
|  So I hope savi should resolve it.
|  
|  thanks,
|  Jun Bi
|  
|  
|  
|  >
|  > Regards, marcelo
|  >
|  >>
|  >> For static address, it's just the configure SAVI-switch ports and a
|  >> couple of paragraph in SAVI-framework.
|  >>
|  >> For manual address, I think it equals stateless (in IPv6 and IPv4).No
|  >> matter in IPv6 or IPv4, we should handle DoS attack on address
|  >> exhausting. One of possible way to handle it is discussed in section
20
|  >> Binding Number Limitation in draft-bi-stateless-01.
|  >>
|  >> thanks,
|  >> Jun Bi
|  >>
|  >>
|  >> --------------------------------------------------
|  >> From: "marcelo bagnulo braun" <[email-masked]>
|  >> Sent: Wednesday, October 20, 2010 9:50 PM
|  >> To: <[email-masked]>
|  >> Subject: Re: [savi] Comments to draft-ietf-savi-framework-00
|  >>
|  >>>  I understand Alberto is talking about manually configured bindings
in
|  >>> the SAVI device, which seems one possible way to support manually
|  >>> configured addresses.
|  >>> I think the first question to ask to the WG is whether we think we
need
|  >>> to support manually configured bindings in the SAVI devices. If yes,
|  >>> then we need to provide guidelines of how to configure the ports,
|  >>> whether the binding need to be configured in all the devices of the
|  >>> perimter or only in one and so on.
|  >>> I believe this should be a couple of paragrpahs, and if that is the
|  >>> case, including this in the framework document seems a good place to
put
|  >>> it.
|  >>>
|  >>> The point you raise, is whether we should include ARP snooping based
|  >>> configuration for IPv4 addresses. This was initially included in the
|  >>> FCFS document and it was dropped because the WG thought it was a bad
|  >>> idea. The main reason for that is that given that the IPv4 address
space
|  >>> allocated to a IPv4 subnet is small (in the order of hundres of
|  >>> addresses) it would be fairly easy for an attacker to perform a DoS
|  >>> attakc and create bindings for all the addresses in a given
subnetwork,
|  >>> and not allowing any other host to access to an address.
|  >>>
|  >>> Regards, marcelo
|  >>>
|  >>>
|  >>> El 20/10/10 15:38, Jun Bi escribió:
|  >>>>
|  >>>> *From:* Alberto García <mailto:[email-masked]>
|  >>>> *Sent:* Wednesday, October 20, 2010 9:11 PM
|  >>>> *To:* [email-masked] <mailto:[email-masked]>
|  >>>> *Subject:* [savi] Comments to draft-ietf-savi-framework-00
|  >>>>
|  >>>> Hi,
|  >>>>
|  >>>> After reading the savi-framework document, I have some comments:
|  >>>>
|  >>>> - I think the case in which address configuration is being done
|  >>>> manually is not covered appropriately by the framework. First, it
|  >>>> should appear in the 'IP address assignment method' section.
Besides,
|  >>>> some kind of mechanism definition should be specified for manual
|  >>>> address configuration which would suit to the "protection perimeter"
|  >>>> model. The model should include rules such as 'discard everything
|  >>>> coming from a Validating port unless a manually created binding
exist',
|  >>>> 'accept everything coming from a Trusted port'. Maybe this could
suit
|  >>>> into the framework document, although maybe it would require more
|  than
|  >>>> Informational 'intended status'.
|  >>>>
|  >>>> (side comment: when interaction between different address
configuration
|  >>>> mechanisms were to be addressed, manually configured addresses
should
|  >>>> also be taken into account, since the SAVI device should defend the
|  >>>> manual configuration somehow - for example, when a host connected to
|  >>>> another SAVI device tries to use SLAAC to configure the same
address).
|  >>>>
|  >>>> junbi: thanks to the comment.
|  >>>>
|  >>>> I think for SAVI IPv6, user manually configured address = SLAAC.
|  >>>>
|  >>>> For SAVI IPv4, draft-bi-stateless-01 (attached) described the
solution
|  >>>> for IPv4 manually configured address by snooping ARP packets.
|  >>>>
|  >>>> I propose Marcelo to merge this part of draft-bi-stateless-01 into
the
|  >>>> SAVI SLAAC solution draft.
|  >>>>
|  >>>> Thanks,
|  >>>>
|  >>>> - In section 4, when talking about the 'protection perimeter', I
|  >>>> think some considerations about the security risks of changes in the
|  >>>> topology of the switches should be stated. In section 5 (Reliability
|  >>>> Optimizations), it is stated that legitimate packets can be lost if
the
|  >>>> link topology changes, but the problem is even harder: some
resulting
|  >>>> topologies could be intrinsically non-defendable, for example, if
the
|  >>>> perimeter is breached by a topology change. This is common to all
SAVI
|  >>>> solutions, so I think this comment should be in the framework
document.
|  >>>>
|  >>>> - There is also one concept that should appear anywhere in the
document
|  >>>> (maybe section 5): SAVI solutions are defined in general to support
|  >>>> host mobility (in the sense of hosts that change their attaching
points
|  >>>> from one layer-2 anchor to a different one - such as changing the
port
|  >>>> of attachment). This is a nice feature provided by SAVI that should
be
|  >>>> presented.
|  >>>>
|  >>>> junbi: yes, L2 mobility is the scope in SAVI charter.
|  >>>>
|  >>>> Finally, one nit: in ref [BA2007],
|  >>>>
|  >>>> s/Fred, F./Baker, F.
|  >>>>
|  >>>> Besides, I think the document is well-written and provides useful
|  >>>> information.
|  >>>>
|  >>>> Regards,
|  >>>>
|  >>>> Alberto
|  >>>>
|  >>>>
------------------------------------------------------------------------
|  >>>>
|  >>>> _______________________________________________
|  >>>> savi mailing list
|  >>>> [email-masked]
|  >>>> https://www.ietf.org/mailman/listinfo/savi
|  >>>>
|  >>>>
|  >>>> _______________________________________________
|  >>>> savi mailing list
|  >>>> [email-masked]
|  >>>> https://www.ietf.org/mailman/listinfo/savi
|  >>>
|  >>> _______________________________________________
|  >>> savi mailing list
|  >>> [email-masked]
|  >>> https://www.ietf.org/mailman/listinfo/savi
|  >>>
|  >>
|  >
|  _______________________________________________
|  savi mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi

---

From: "Bi Jun" <[email-masked]>
Date: Wed, 20 Oct 2010 23:40:18 +0800

--------------------------------------------------
From: "Alberto García" <[email-masked]>
Sent: Wednesday, October 20, 2010 11:23 PM
To: "'Bi Jun'" <[email-masked]>; "'marcelo bagnulo braun'" 
<[email-masked]>
Cc: <[email-masked]>
Subject: RE: [savi] Comments to draft-ietf-savi-framework-00

> administrator knows in advance because it knows the MAC address of the 

Hi Alerto,

Thanks for the explanation.
I know you originally didn't care. But I do care the manual addresses for 
IPv4 case, because in the real world, it does bring problems as I stated in 
last several emails (student configures any IPv4 address at his host, but 
conflicts with others addresses or spoof others addresses). I think savi 
should helps to fix it.

thanks,
Jun

> Bi

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Oct 2010 14:31:37 -0400

There seem to be two different kinds of static configuration being 
mixed, and implications of both being unstated.

Alberto, if I am reading you correctly, you are trying to deal with 
static address assignment that is done manually, and must be preserved 
over time.
This seems to implicitly assume that devices getting this sort of 
assignment can never change what port they are attached to without 
significant manual intervention on the relevant SAVI switches.  I am 
concerned that even for fixed servers, they do get plugged into 
different switch ports, and that the SAVI configuration is unlikely to 
be correct.
This assumes that in the SLAAC environment the SAVI switch will defend 
the IP address assignment even when the end device is not present. 
While understandable, that is a new function for the switch that has not 
been specified.
In the DHCP environment, this assumes that the DHCP server is also 
configured to not use that assigned address.  That sort of avoidance is 
already supported, but this means that the same information needs to be 
configured manually in three different places.  That is highly error prone.

The other kind of manual assignment is where a host, possibly prompted 
by its user, tries to choose a specific IP address.  This case seems to 
actually turn into an existing case.  it is either a DHCP "renewal" or a 
SLAAC readvertisement, where the value in either case is chosen rather 
than random.  This works with the existing protocols.

Yes, the reserved manual configuration case needs to be dealt with in 
the mixed mode document.  But we have to work otu ways of keeping the 
work load tractable or SAVI will appear to have failed.

Yours,
Joel

On 10/20/2010 11:23 AM, Alberto García wrote:
> |  From: "marcelo bagnulo braun"<[email-masked]>
> |  To: "Bi Jun"<[email-masked]>
> |  Cc:<[email-masked]>
> |>   El 20/10/10 16:28, Bi Jun escribió:
> |>>  Hi, Marcelo,
> |>>
> |>>  Let me have more sentences on it. At operation terms in our campus
> |>>  network, usually, "manual address" means "user manually configured
> |>>  address at its host", not "static address" (which is assigned by
> |>>  administrator by off-line registration and manually configured at
> switch
> |>>  by administrator).
> |>
> |>  sorry, i thought i understood this, but now i am not sure.
> |>  So, in the manual address case, where does the user obtains the address
> |>  from? It is not assigned by off line admin?
> |
> |>
> |>  Regards, marcelo
> |>
> |>>
> |>>  For static address, it's just the configure SAVI-switch ports and a
> |>>  couple of paragraph in SAVI-framework.
> |>>
> |>>  For manual address, I think it equals stateless (in IPv6 and IPv4).No
> |>>  matter in IPv6 or IPv4, we should handle DoS attack on address
> |>>  exhausting. One of possible way to handle it is discussed in section
> 20
> |>>  Binding Number Limitation in draft-bi-stateless-01.
> |>>
> |>>  thanks,
> |>>  Jun Bi
> |>>
> |>>
> |>>  --------------------------------------------------
> |>>  From: "marcelo bagnulo braun"<[email-masked]>
> |>>  Sent: Wednesday, October 20, 2010 9:50 PM
> |>>  To:<[email-masked]>
> |>>  Subject: Re: [savi] Comments to draft-ietf-savi-framework-00
> |>>
> |>>>   I understand Alberto is talking about manually configured bindings
> in
> |>>>  the SAVI device, which seems one possible way to support manually
> |>>>  configured addresses.
> |>>>  I think the first question to ask to the WG is whether we think we
> need
> |>>>  to support manually configured bindings in the SAVI devices. If yes,
> |>>>  then we need to provide guidelines of how to configure the ports,
> |>>>  whether the binding need to be configured in all the devices of the
> |>>>  perimter or only in one and so on.
> |>>>  I believe this should be a couple of paragrpahs, and if that is the
> |>>>  case, including this in the framework document seems a good place to
> put
> |>>>  it.
> |>>>
> |>>>  The point you raise, is whether we should include ARP snooping based
> |>>>  configuration for IPv4 addresses. This was initially included in the
> |>>>  FCFS document and it was dropped because the WG thought it was a bad
> |>>>  idea. The main reason for that is that given that the IPv4 address
> space
> |>>>  allocated to a IPv4 subnet is small (in the order of hundres of
> |>>>  addresses) it would be fairly easy for an attacker to perform a DoS
> |>>>  attakc and create bindings for all the addresses in a given
> subnetwork,
> |>>>  and not allowing any other host to access to an address.
> |>>>
> |>>>  Regards, marcelo
> |>>>
> |>>>
> |>>>  El 20/10/10 15:38, Jun Bi escribió:
> |>>>>
> |>>>>  *From:* Alberto García<mailto:[email-masked]>
> |>>>>  *Sent:* Wednesday, October 20, 2010 9:11 PM
> |>>>>  *To:* [email-masked]<mailto:[email-masked]>
> |>>>>  *Subject:* [savi] Comments to draft-ietf-savi-framework-00
> |>>>>
> |>>>>  Hi,
> |>>>>
> |>>>>  After reading the savi-framework document, I have some comments:
> |>>>>
> |>>>>  - I think the case in which address configuration is being done
> |>>>>  manually is not covered appropriately by the framework. First, it
> |>>>>  should appear in the 'IP address assignment method' section.
> Besides,
> |>>>>  some kind of mechanism definition should be specified for manual
> |>>>>  address configuration which would suit to the "protection perimeter"
> |>>>>  model. The model should include rules such as 'discard everything
> |>>>>  coming from a Validating port unless a manually created binding
> exist',
> |>>>>  'accept everything coming from a Trusted port'. Maybe this could
> suit
> |>>>>  into the framework document, although maybe it would require more
> |  than
> |>>>>  Informational 'intended status'.
> |>>>>
> |>>>>  (side comment: when interaction between different address
> configuration
> |>>>>  mechanisms were to be addressed, manually configured addresses
> should
> |>>>>  also be taken into account, since the SAVI device should defend the
> |>>>>  manual configuration somehow - for example, when a host connected to
> |>>>>  another SAVI device tries to use SLAAC to configure the same
> address).
> |>>>>
> |>>>>  junbi: thanks to the comment.
> |>>>>
> |>>>>  I think for SAVI IPv6, user manually configured address = SLAAC.
> |>>>>
> |>>>>  For SAVI IPv4, draft-bi-stateless-01 (attached) described the
> solution
> |>>>>  for IPv4 manually configured address by snooping ARP packets.
> |>>>>
> |>>>>  I propose Marcelo to merge this part of draft-bi-stateless-01 into
> the
> |>>>>  SAVI SLAAC solution draft.
> |>>>>
> |>>>>  Thanks,
> |>>>>
> |>>>>  - In section 4, when talking about the 'protection perimeter', I
> |>>>>  think some considerations about the security risks of changes in the
> |>>>>  topology of the switches should be stated. In section 5 (Reliability
> |>>>>  Optimizations), it is stated that legitimate packets can be lost if
> the
> |>>>>  link topology changes, but the problem is even harder: some
> resulting
> |>>>>  topologies could be intrinsically non-defendable, for example, if
> the
> |>>>>  perimeter is breached by a topology change. This is common to all
> SAVI
> |>>>>  solutions, so I think this comment should be in the framework
> document.
> |>>>>
> |>>>>  - There is also one concept that should appear anywhere in the
> document
> |>>>>  (maybe section 5): SAVI solutions are defined in general to support
> |>>>>  host mobility (in the sense of hosts that change their attaching
> points
> |>>>>  from one layer-2 anchor to a different one - such as changing the
> port
> |>>>>  of attachment). This is a nice feature provided by SAVI that should
> be
> |>>>>  presented.
> |>>>>
> |>>>>  junbi: yes, L2 mobility is the scope in SAVI charter.
> |>>>>
> |>>>>  Finally, one nit: in ref [BA2007],
> |>>>>
> |>>>>  s/Fred, F./Baker, F.
> |>>>>
> |>>>>  Besides, I think the document is well-written and provides useful
> |>>>>  information.
> |>>>>
> |>>>>  Regards,
> |>>>>
> |>>>>  Alberto
> |>>>>
> |>>>>
> |>>>>
> |>>>>  _______________________________________________
> |>>>>  savi mailing list
> |>>>>  [email-masked]
> |>>>>  https://www.ietf.org/mailman/listinfo/savi
> |>>>>
> |>>>>
> |>>>>  _______________________________________________
> |>>>>  savi mailing list
> |>>>>  [email-masked]
> |>>>>  https://www.ietf.org/mailman/listinfo/savi
> |>>>
> |>>>  _______________________________________________
> |>>>  savi mailing list
> |>>>  [email-masked]
> |>>>  https://www.ietf.org/mailman/listinfo/savi
> |>>>
> |>>
> |>