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

Rémi Després <remi.despres <at> free.fr>
2010-09-02 07:57:33 GMT

+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.

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.
>

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

Warren Kumari <warren <at> kumari.net>
2010-09-10 20:09:13 GMT

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).

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

Re: Your availability for a pre-WGLC document review

Joel M. Halpern <jmh <at> joelhalpern.com>
2010-09-14 02:33:15 GMT

[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.

Re: Your availability for a pre-WGLC document review

Fred Baker <fred <at> cisco.com>
2010-09-14 04:03:12 GMT

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.

BOFs for IETF-79

Jari Arkko <jari.arkko <at> piuha.net>
2010-09-14 10:01:20 GMT

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

Re: Your availability for a pre-WGLC document review

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?

* 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)

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.