<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [GTER] Speedy business - novela de roteamento</TITLE>
<META content="MSHTML 5.50.4616.200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=998172917-20052002><FONT face=Arial color=#0000ff
size=2>Discordo da sua opinião. Por que o portal não é aplicável ao usuário
business ? Concordo que a arquitetura do serviço muda bastante, entretanto não
invalida a utilização do portal. Por exemplo, no caso business, o gerente
de TI da empresa poderia ter visibilidade dos links das filiais via portal, e
provisioná-los.</FONT></SPAN></DIV>
<DIV><SPAN class=998172917-20052002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=998172917-20052002><FONT face=Arial color=#0000ff
size=2>Acredito que a discussão à respeito do serviço business da Telefonica
esteja muito mais ligada a arquitetura do serviço adotado pelo provedor do
que a disponibilidade de soluções disponíveis no mercado para endereçar esse
segmento.</FONT></SPAN></DIV>
<DIV><SPAN class=998172917-20052002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=998172917-20052002><FONT face=Arial color=#0000ff
size=2>--</FONT></SPAN></DIV>
<DIV><SPAN class=998172917-20052002><FONT face=Arial color=#0000ff
size=2>Rodrigo</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Renato Wada
[mailto:renato_wada@optiglobe.com.br]<BR><B>Sent:</B> Monday, May 20, 2002
10:08 AM<BR><B>To:</B> gter@eng.registro.br<BR><B>Subject:</B> RE: [GTER]
Speedy business - novela de roteamento<BR><BR></FONT></DIV><!-- Converted from text/plain format -->
<P><FONT size=2><BR>-----BEGIN PGP SIGNED MESSAGE-----<BR>Hash: SHA1<BR><BR>Oi
Rodrigo,<BR><BR> A sua solução é mais ou menos o que pessoal
esta adotando como padrão para<BR>usuários domesticos. O problema é quando
temos um produto como o Speedy<BR>Business. Nestes casos, não se pode esperar
que algum usuário se autentique.<BR>Imagine que um servidor de um cliente com
IP fixo caia num fim de semana. O<BR>administrador teria que ir até a empresa
para subir o servidor ou esperar até a<BR>segunda-feira?<BR><BR>[]s,<BR><BR>-
--<BR>Renato Mitsuo Wada<BR>Network Security Analyst<BR>OptiGlobe
Communications<BR><A
href="http://www.optiglobe.com.br">http://www.optiglobe.com.br</A> <<A
href="http://www.optiglobe.com.br/">http://www.optiglobe.com.br/</A>> <BR><BR>-
-----Original Message-----<BR>From: Loureiro, Rodrigo [<A
href="mailto:RLoureiro@unispherenetworks.com">mailto:RLoureiro@unispherenetworks.com</A>]<BR>Sent:
Monday, May 20, 2002 12:27 PM<BR>To: 'gter@eng.registro.br'<BR>Subject: RE:
[GTER] Speedy business - novela de roteamento<BR><BR><BR>Uma forma de
contornar essa vulnerabilidade seria dividindo o leasing em duas<BR>partes:
token and permanent address. No primeiro caso, o servidor DHCP built-in<BR>no
Edge Router/BRAS atribui um endereço transiente, o qual possui um escopo
de<BR>roteamento limitado no domínio do backbone/provedor, limitando esse
escopo, por<BR>exemplo, a um portal. Para obter um endereço roteável, o
usuário precisa ir ao<BR>portal de autenticação. Uma vez autenticado, o Edge
Router é informado dessa<BR>mudança de estado e, utilizando
username/senha/domínio entrados no portal, gera<BR>um access request radius no
lugar do usuário final para o servidor radius do<BR>backbone. Durante o
processo de autorização, pode ser retornado um atributo de<BR>pool IP, que
será referenciado pelo Edge Router para designação do endereço<BR>permanente
ao usuário final.<BR><BR><BR>Abraços,<BR><BR>- --<BR>Rodrigo Loureiro<BR><BR>-
-----Original Message-----<BR>From: Joao Carlos Mendes Luis [<A
href="mailto:jonny@jonny.eng.br">mailto:jonny@jonny.eng.br</A>]<BR>Sent:
Monday, May 20, 2002 7:55 AM<BR>To: gter@eng.registro.br<BR>Subject: Re:
[GTER] Speedy business - novela de roteamento<BR><BR><BR>Oi
Rubens,<BR><BR>Rubens Kuhl Jr. wrote:<BR><BR><BR>Vc pode autenticar o DHCP em
função de parâmetros fora do controle do<BR>usuário como VC ATM, DSLAM Port
etc.<BR><BR>Quando o meio é não compartilhado, e voce tem essa informação,
tudo bem. Mas e<BR>em meios compartilhados, como
Cable?<BR><BR><BR><BR>Agora, se alguém tem poder administrativo sobre sua
rede, DHCP-forging é<BR>o menor dos seus
problemas...<BR><BR><BR>????<BR><BR>Eu estava preocupado com DHCP autenticado
por MAC, que é algo facilimo de mudar<BR>no desktop. Isso nao tem nada a
ver com poder
administrativo.<BR><BR><BR><BR><BR><BR><BR>Rubens<BR><BR><BR><BR>-
-----Original Message-----<BR>From: gter-admin@eng.registro.br [ <A
href="mailto:gter-admin@eng.registro.br">mailto:gter-admin@eng.registro.br</A>]
On<BR>Behalf Of Joao Carlos Mendes Luis<BR>Sent: Saturday, May 18, 2002 10:06
PM<BR>To: gter@eng.registro.br<BR>Subject: Re: [GTER] Speedy business -
novela de roteamento<BR><BR><BR>Carlos Ribeiro wrote:<BR><BR>On Fri 17 May
2002 20:32, you wrote:<BR><BR>Existe uma opção que é o DHCP autenticado por
NAS-Port/VC(ADSL) ou<BR>MAC(Cable).<BR><BR>Aaargh! DHCP não! e agora, ainda
tem o CLIIPS (algo do tipo 'client<BR>less IP alguma coisa', um DHCP
melhorado)... tá certo que tem algumas<BR>aplicações onde isso pode até fazer
sentido (tipo cable modem), mas eu<BR><BR>sinceramente não consigo confiar em
uma solução baseada em DHCP... (eu<BR><BR>admito o preconceito
:-)<BR><BR><BR> DHCP é OTIMO para evitar ter que passar os
dados pro usuário. Eu<BR>sugiro uso de DHCP até mesmo para quem tem IP
Fixo. Mas autenticar por<BR>DHCP ou MAC não pode ser sujeito a furos de
seguranca?<BR><BR>
Jonny<BR><BR><BR><BR><BR>=======================================<BR><BR>This
email message is for the sole use of the intended recipient (s) and
may<BR>contain confidential and privileged information, including without
limitation,<BR>Confidential and/or Proprietary Information belonging to
Unisphere Networks,<BR>Inc. Any unauthorized review, use, disclosure or
distribution is prohibited. If<BR>you are not the intended recipient, please
contact the sender by reply email<BR>and destroy all copies of the original
message.<BR><BR><BR>-----BEGIN PGP SIGNATURE-----<BR>Version: PGP
7.0.4<BR>Comment: OptiGlobe
Communications<BR><BR>iQA/AwUBPOktdSwhsoAekreeEQIQzgCeKQUgkYJhHkVZW0cfJ5kmnXRKBXYAnRqp<BR>ojAmS5EodrcGE/29moLqUoNe<BR>=4sRm<BR>-----END
PGP SIGNATURE-----<BR></FONT></P></BLOCKQUOTE></BODY></HTML>
<BR>
<P><FONT SIZE=2 FACE="Arial">======================================= </FONT></P>
<P><FONT SIZE=2 FACE="Arial">This email message is for the sole use of the intended recipient (s) and may contain confidential and privileged information, including without limitation, Confidential and/or Proprietary Information belonging to Unisphere Networks, Inc. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.</FONT></P>