Xu Xiaohu | 1 Sep 03:36 2010

Re: Alternative option for IP-only L2VPN?//re: New VersionNotification for draft-xu-virtual-subnet-02

Hi Himanshu,

> -----邮件原件-----
> 发件人: Himanshu Shah [mailto:hshah <at> force10networks.com]
> 发送时间: 2010年8月31日 23:34
> 收件人: Xu Xiaohu; l2vpn <at> ietf.org
> 抄送: int-area <at> ietf.org; l3vpn <at> ietf.org; rtgwg <at> ietf.org
> 主题: RE: Alternative option for IP-only L2VPN?//re: New
VersionNotification
> for draft-xu-virtual-subnet-02
> 
> Comments in line..
> 
> Thanks,
> himanshu
> 
> -----Original Message-----
> From: l2vpn-bounces <at> ietf.org [mailto:l2vpn-bounces <at> ietf.org] On Behalf Of
Xu
> Xiaohu
> Sent: Friday, August 27, 2010 11:40 PM
> To: l2vpn <at> ietf.org
> Cc: int-area <at> ietf.org; l3vpn <at> ietf.org; rtgwg <at> ietf.org
> Subject: re: Alternative option for IP-only L2VPN?//re: New Version
> Notification for draft-xu-virtual-subnet-02
> 
> Hi all,
> 
> Since there is no comment till now, let me make some comments on the IPLS
> first.
(Continue reading)

Xu Xiaohu | 1 Sep 08:22 2010

Re: Alternative option for IP-only L2VPN?//re: New VersionNotification for draft-xu-virtual-subnet-02

Hi all,

An updated version of Virtual Subnet (VS) is now available at
http://tools.ietf.org/html/draft-xu-virtual-subnet-03.

Major technical changes include:
1) A section of VS vs VPLS is added.
2) A section of VS vs IPLS is added.
3) Multicast/broadcast mechanism is simplified.
4) CE host discovery mechanism is completed by adding an option of ARP
request for ALL-Systems multicast group address (i.e., 224.0.0.1).

Best wishes,
Xiaohu

> -----邮件原件-----
> 发件人: Himanshu Shah [mailto:hshah <at> force10networks.com]
> 发送时间: 2010年8月31日 23:34
> 收件人: Xu Xiaohu; l2vpn <at> ietf.org
> 抄送: int-area <at> ietf.org; l3vpn <at> ietf.org; rtgwg <at> ietf.org
> 主题: RE: Alternative option for IP-only L2VPN?//re: New
VersionNotification
> for draft-xu-virtual-subnet-02
> 
> Comments in line..
> 
> Thanks,
> himanshu
> 
> -----Original Message-----
(Continue reading)

Rémi Després | 2 Sep 09:57 2010
Picon

Re: Review of draft-narten-ipv6-3177bis-48boundary-05

+1

Le 20 août 2010 à 22:35, Brian E Carpenter a écrit :

> On 2010-08-21 08:23, Fred Baker wrote:
>> On Aug 20, 2010, at 12:49 PM, Eric Gray wrote:
>> 
>>> 	Having multiple chunk sizes seems to me to be a recipe for in-
>>> efficient use of address space in general.  
>> 
>> speaking for myself, I think a one-size-fits-all model has the same effect. In my home, today, I have two
LANs; I could easily imagine expanding that to half a dozen or even a dozen in various scenarios. Giving me a
/48 is a waste of address space - it's at least 4096 times as much as I need, and would give my upstream the
ability to address 4095 more homes like mine if they were to allocate /60's. To the extent that they are
paying their RIR for address space, er, membership, it wastes their money and increases my monthly
payment. 
>> 
>> I think there is a great reason to suggest that access and transit networks to offer their downstreams
/48, /52, /56, and /60 options at various costs. It makes business sense for them, allows them to
reasonably recover their costs without burdening the downstreams, allows for downstreams to number
their networks in ways they like and reasonably move up to shorter prefixes when they need to, and (since I
didn't mention /64) ensures that the smallest users - residential/SOHO - have options for routing within
the home as appropriate.
> 
> Another +1 to Fred. I was originally a strong advocate of Eric's view,
> in fact I take credit/blame for a lot of RFC3177, but I believe that
> experience, especially the remarkable success of CIDR in controlling
> the growth of PA routes for IPv4, and the acquired wisdom of the RIRs
> in administering CIDR, have shown that there is no efficiency benefit
> in fixed chunks.
(Continue reading)

Bob Hinden | 8 Sep 21:38 2010
Picon

Re: introducing a new IPv4 option [was RE: [BEHAVE] Revealing identity of TCP client connection when sharing IPv4 address]


On Aug 31, 2010, at 11:33 AM, Dan Wing wrote:

> A paper was published in 2004 which analyzed the success of new IP options
> and new TCP options,
> 
>  "Measuring Interactions Between Transport Protocols and Middleboxes"
>  Alberto Medina, Mark Allman, Sally Floyd
>  http://conferences.sigcomm.org/imc/2004/papers/p336-medina.pdf
> 
> In Section 4.3, it showed a new IP Option resulted in a 70% connection
> failure, whereas
> Section 4.4 shows a new TCP option resulted in only a 0.2% connection
> failure.  I do 
> not expect things have improved on the Internet for IP options, and my
> testing with 
> nmap to the top 500 websites also has very high failure when sending an TCP
> SYN
> with an IP option.
> 
> Using an IP Option on today's Internet seems unworkable, unless we do
> something
> creative like sending two packets (one with the IP option, one without) and
> react accordingly.  This will probably break UDP-based application protocols
> 
> that don't expect packets to arrive twice, and of course doubles traffic for
> TCP until the address sharing device learns if the server supports or
> rejects
> IP options - which is more state to maintain.
> 
(Continue reading)

Warren Kumari | 10 Sep 22:09 2010
Picon

Asking for int-area review of: draft-ietf-opsec-ip-security-03.txt

Hey all,

This document (draft-ietf-opsec-ip-security) has completed OpSec WG last call, but due to the breadth
and scope of this the OPS ADs have asked that it get additional socializing in the int-area:

http://datatracker.ietf.org/doc/draft-ietf-opsec-ip-security/

(This was also presented by Joel Jaeggli in the int-area meeting at IETF78)

While Joe Touch has already provided very valuable int-area perspective, additional review before
submitting to the IESG would be great....

We realize that it is a large document and that reviewing it will take significant time, but would really
appreciate your views and input within 2 weeks (by 00:00 09/25/2010) if you could.

Thank you
Warren Kumari (OpSec WG co-chair).
Christian Vogt | 13 Sep 22:58 2010
Picon

Reviews of "IP Router Alert Considerations" document

Folks, FYI:

We have asked Fred Baker, Joel Halpern, Suresh Krishnan, and Ron Bonica to review Francois' document "IP
Router Alert Considerations and Usage" [1].  Based on these reviews, and based on the reviews of other
working group members, we will decide on whether the document is ready for working group last call.  Your
participation in this discussion will be appreciated.

- Christian

[1] http://tools.ietf.org/html/draft-ietf-intarea-router-alert-considerations
Joel M. Halpern | 14 Sep 04:33 2010

Re: Your availability for a pre-WGLC document review

[Christian asked that we bring the review discussion to the list, with 
all context.  Thus, I am sending my reply, based on Francois' comments 
on my review, to the list with all context.]

Unfortunately, with regard to the arguments for their being a difference 
between Router Alert and BGP, I think one could reasonably disagree with 
all three points in the document.  I am not sure it is worth arguing, 
since whether the distinction in this dimension is real or not does not 
change the point of the document.  And the point of the document is 
quite well taken.  The three points you list are, simplified, core 
isolation, information termination, and configured peerings.

Given that there are not clear distinctions in practice between core 
routers and edge routers (there are routers that are primarily for 
internal use, and routers that are primarily for peering use, and 
routers that are primarily for customer facing use, but the distinctions 
all get blurred), I am not sure the first point in this portion of the 
document works.

The second point, while apparently accurate, does not match teh reality 
of issues that have been observed where incorrect information can get 
propagated through the BGP system, causing quite widespread problems. 
(The details vary from case to case, but the point is that many kinds of 
problems have managed to spread.)

The argument for their being less of na issue since peerings are 
configured is probably true.  However, given that the security 
mechanisms currently are deployed in very weak fashions (keys basically 
never change, for example), there are still very similar vulnerabilities 
there.
(Continue reading)

Fred Baker | 14 Sep 06:03 2010
Picon

Re: Your availability for a pre-WGLC document review


On Sep 13, 2010, at 9:33 PM, Joel M. Halpern wrote:

> Given that there are not clear distinctions in practice between core routers and edge routers (there are
routers that are primarily for internal use, and routers that are primarily for peering use, and routers
that are primarily for customer facing use, but the distinctions all get blurred), I am not sure the first
point in this portion of the document works.

I really wish the IETF would talk about core-facing interfaces and edge-facing interfaces than about core
and edge routers. Edge-facing interfaces face customers and therefore have link speeds and policy
appropriate to a customer SLA; core-facing interfaces don't, and are driven by very different
requirements. In any non-trivial network, edge routers have many edge-facing interfaces and a few
core-facing interfaces.

The kind of router we generally call a "core router" is probably one that has only core-facing interfaces -
it directly serves no customers, but may connect to one or more peer or upstream networks. That,
unfortunately, is a distinction easier made in theory than in practice.

Even that is well over-simplified. But it at least makes the attributes one might want to talk about
attributes of the interface rather than of the router, which is at least technically correct at that level.
Jari Arkko | 14 Sep 12:01 2010
Picon

BOFs for IETF-79

We have received four proposals for BOFs in for the upcoming meeting (on 
distributed mobility management, ARP improvements, light-weight IP 
stack, and name-based sockets). And more in the other areas. In about a 
week we will be making decisions about what to do about these things. If 
you are interested in participating the discussions or have opinions to 
share, I know the both the organizers of these efforts as well as the 
ADs would appreciate feedback and additional participation.

More information about these efforts and their mailing lists are shown 
in http://tools.ietf.org/bof/trac/wiki/WikiStart

Jari and Ralph
Francois Le Faucheur | 14 Sep 14:45 2010
Picon

Re: Your availability for a pre-WGLC document review

Hello Joel,

Your considerations about the three BGP points are certainly valid. I don't think they completely invalidate the points, but certainly qualify them/tone them down.

But all the more, I really see value in relating (as objectively as possible) the security issues of RAO (which common wisdom would have you rate as utterly unacceptable) to security issues of other protocols that also open up a hole in routers control plane like BGP (which is obviously widely accepted/tolerated/put-up-with/...). This question comes up all the time and would benefit from a thoughtful answer.
  
Would it work for you if we kept the BGP discussion and enhanced it to reflect your points?
eg (in simplified form): 
* core routers are isolated from DOS attacks on Edge routers; however, distinction core/edge is becoming blurred
* BGP policy control would normally filter undesirable stuff; however, there are known occurrences where incorrect information did get propagated 
* configured peers facilitate filtering from other sources; however, bad practices can result in this being compromised.
(and perhaps we can refrain from making a judgment call that the BGP issues are less "serious" and simply present the above as "considerations on the differences") 

Again, I really feel this sheds (needed) light on the topic of control plane holes (and therefore on RAO security considerations).

Thanks much

Francois 

On 14 Sep 2010, at 04:33, Joel M. Halpern wrote:

[Christian asked that we bring the review discussion to the list, with all context.  Thus, I am sending my reply, based on Francois' comments on my review, to the list with all context.]

Unfortunately, with regard to the arguments for their being a difference between Router Alert and BGP, I think one could reasonably disagree with all three points in the document.  I am not sure it is worth arguing, since whether the distinction in this dimension is real or not does not change the point of the document.  And the point of the document is quite well taken.  The three points you list are, simplified, core isolation, information termination, and configured peerings.

Given that there are not clear distinctions in practice between core routers and edge routers (there are routers that are primarily for internal use, and routers that are primarily for peering use, and routers that are primarily for customer facing use, but the distinctions all get blurred), I am not sure the first point in this portion of the document works.

The second point, while apparently accurate, does not match teh reality of issues that have been observed where incorrect information can get propagated through the BGP system, causing quite widespread problems. (The details vary from case to case, but the point is that many kinds of problems have managed to spread.)

The argument for their being less of na issue since peerings are configured is probably true.  However, given that the security mechanisms currently are deployed in very weak fashions (keys basically never change, for example), there are still very similar vulnerabilities there.

Yours,
Joel

On 9/13/2010 4:29 PM, Francois Le Faucheur wrote:
Hello Joel,

Thanks for your comments. Thoughts embedded:

On 13 Sep 2010, at 21:43, Joel M. Halpern wrote:

This document appears to be in good shape. I do have one minor
concern, and one quibble.

THe minor concern is that the document implies that encapsulating
packets with IP options is easily done and a general answer. It is
easily done when MPLS is used across an administrative domain. With
conventional IP networks, knowing where to send such an encapsulated
datagram is not so easy. For the MPLS case specifically, it works, and
works well. Could some clarifying text be added to distinguish these
two case.

Agreed. The two cases will be distinguished..


The quibble is with the description of how safe BGP is from these
attacks. I believe the text is over-optimistic relative to the degree
of protection available with current BGP.

The current text does not intend to make statements about how safe or
unsafe current BGP is.
It only aims at explaining why Router Alert has a few additional
security concerns beyond those that exist with other (commonly deployed)
scenarios also involving opening up a hole in routers control plane
(like BGP is doing).

Is there any specific statement that contrast BGP security with RAO
security that is not correct?

Thanks

Francois


As I said, other than those two issues, the document looks good.
Yours,
Joel M. Halpern

On 9/12/2010 2:20 AM, Christian Vogt wrote:
Fred, Joel, and Suresh:

The Intarea working group has a deliverable,
draft-ietf-intarea-router-alert-considerations [1], which we believe
is near-ready for working group last call. However, before initiating
the last call, we would like to get some experts to review the
document. Would you be able to provide such a review?

Many thanks in advance! Please send your comments to the Intarea
working group mailing list.

- Christian


[1]
http://tools.ietf.org/html/draft-ietf-intarea-router-alert-considerations



*
Francois Le Faucheur*
*Distinguished Engineer*
*Corporate Development*
flefauch <at> cisco.com <mailto:flefauch <at> cisco.com>
Phone: *+33 49 723 2619*
Mobile: *+33 6 19 98 50 90*




*Cisco Systems France*
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com <http://www.cisco.com>



Think before you print.

This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille
Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les
Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur
de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html


_______________________________________________
Int-area mailing list
Int-area <at> ietf.org
https://www.ietf.org/mailman/listinfo/int-area


Francois Le Faucheur
Distinguished Engineer
Corporate Development
flefauch <at> cisco.com
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90


Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 
 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html


_______________________________________________
Int-area mailing list
Int-area <at> ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Gmane