headers
Kanchei Loa | 1 Apr 09:01
Picon

RE: Time shifitng/future redirection attacks


marcelo bagnulo wrote:

> I don't think that the decision is obvious but I think it is very
> importatn
> ti understand the additional vulnerabilities that we are
> introducing. It may
> be acceptable to introduce them, though.
>

I would like to point out that vulnerability is not always a bad thing as
portrayed so far. In many situation, it become a feature for the
application. For example, MiTM vulnerability has been the basis for NAT,
firewall, load balancing proxy server (traffic director), TCP proxy for
wireless subnet and many other so-called value-added network services. They
are very important network components that support the exponential growth of
Internet.

IMHO I suggest the architecture document should provide a balance view on
both security threats and value-added network services. In addition to the
list of security threats, we should also compile a list of value-added
network services. All proposals should be compared by not only the security
threats being eliminated or introduced but also the value-added service
being shutdown, added or refined. They are equally important issues for
deployment and operation.

For example, time shifting/future redirection attacks is a security threat
for "drive-by coffeshop" but it provides a very nice feature for the
"traffic director" whose job is to balance the load of the transport traffic
among a groups of servers. Based on the vulnerability of time
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brian E Carpenter | 1 Apr 12:52
Picon
Favicon

Re: Time shifitng/future redirection attacks

Kanchei,

Kanchei Loa wrote:
> 
> marcelo bagnulo wrote:
> 
> > I don't think that the decision is obvious but I think it is very
> > importatn
> > ti understand the additional vulnerabilities that we are
> > introducing. It may
> > be acceptable to introduce them, though.
> >
> 
> I would like to point out that vulnerability is not always a bad thing as
> portrayed so far. In many situation, it become a feature for the
> application. For example, MiTM vulnerability has been the basis for NAT,
> firewall, load balancing proxy server (traffic director), TCP proxy for
> wireless subnet and many other so-called value-added network services. They
> are very important network components that support the exponential growth of
> Internet.
> 

I really don't want to start a flame-fest here, but the operational phrase
in your comment is "so called". It is precisely to get away from these
disruptive middleboxes that we want to deploy IPv6, and to get well architected
solutions to these problems from WGs such as midcom and opes. If we make
IPv6 MitM-proof we will have done a good thing, and that certainly applies
to multi6.

> IMHO I suggest the architecture document should provide a balance view on
(Continue reading)

Permalink | Reply | 1 comment |
headers
marcelo bagnulo | 1 Apr 16:00
Picon

RE: Identifiers

> So basically we have four permutations of identifiers:
>
> - non-crypto, non-hierarchical
> - crypto, non-hierarchical
> - non-crypto, hierarchical
> - crypto, hierarchical

Well, there are also reachable identifiers, i.e. locators used as
identifiers, i.e. IP addresses

A generic non-crypto identifier may not provide any inherent security means
like for instance a MAC address.
However, IP addresses do provide a light security feature based on
routability. while this security is light, it is probably good enough to
provide the required security for the initial state when using deferred
setup. OTOH, if you use a generic id (non routable) it is possible that you
need a minimum check for it (like for instance verifying the direction of
the communications that are using it)

>
> We probably don't need four different security mechanisms, but more
> than one is likely if we're going to use identifiers from more than one
> category.
>
> > Will be immediate vs. deferred state setup have implications on this?
>
> I don't see how we can defer state setup for identifiers that aren't
> reachable locators.

I just include in the same packet the identifier that i am claiming to own
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kanchei Loa | 1 Apr 22:17
Picon

RE: Time shifitng/future redirection attacks

Brian,

Brian E Carpenter wrote:

> > My point is that the final decision of some security threats 
> > belongs to the
> > application. As the multi6 solution is at network/transport 
> > layer, we should
> > strive to be flexible in negotiating security mechanisms or 
> > lack of it. We
> > should learn the lesson from the deployment and operation of IPsec.
> 
> I agree for attacks (even MitM attacks) against the application 
> layer. But there
> may be MitM attacks that are directed at lower layers. It would 
> be hard to explain
> to the IESG that we chose to ignore those.
> 

Security is always a double edges sword.

I agree with you 100% on the "right way" to do networking and multi6
should be compatible with architectural approaches to these
problems, which is going to be part of future Internet. I also 
understand the sensitivity with IESG if we are perceived to be 
ignoring some attacks in our proposals.

I am not suggesting to ignore those attacks. But considering that 
we have been deploying equipments to do IP networking the 
"wrong" way" for last 15 years, the architecture documents
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rob Austein | 4 Apr 07:00
Favicon
Gravatar

Weekly posting summary for multi6 <at> ops.ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 23.81% |    5 | 29.04% |    23846 | mbagnulo <at> ing.uc3m.es
 14.29% |    3 | 16.28% |    13370 | brc <at> zurich.ibm.com
 14.29% |    3 | 14.34% |    11774 | iljitsch <at> muada.com
 14.29% |    3 | 13.53% |    11113 | erik.nordmark <at> sun.com
  9.52% |    2 |  8.88% |     7297 | loa <at> ieee.org
  4.76% |    1 |  6.33% |     5198 | lear <at> cisco.com
  4.76% |    1 |  3.66% |     3002 | h.soliman <at> flarion.com
  4.76% |    1 |  3.00% |     2467 | sra <at> hactrn.net
  4.76% |    1 |  2.63% |     2164 | jari.arkko <at> piuha.net
  4.76% |    1 |  2.31% |     1897 | kurtis <at> kurtis.pp.se
--------+------+--------+----------+------------------------
100.00% |   21 |100.00% |    82128 | Total

Grunchweather Associates provides this automatic summary on an at-whim
basis at the request of the MULTI6 WG chairs.  Your mileage may vary.
We decline responsibilities, all shapes, all sizes, all colors.
If this script produces broken output, you get to keep both pieces.
Permalink | Reply | 0 comments |
headers
Dave Crocker | 5 Apr 20:57

same time, different venue?

Folks,

BEC> Unfortunately we can't hold the interim meeting in Barcelona. While
BEC> it was OK for a majority of the people who responded, the local
BEC> organizers have been unable to find a room and the situation for
BEC> hotel rooms that week is terrible (except for those who book
BEC> through the INET conference).

Since the Barcenlona INET time and venue were ok for participants, and
the problem was "merely" with site logistics, what about holding the
meeting elsewhere, but nearby, at the same time (or a day earlier, so
as not to conflict with the first day of the INET conference?

Presumably this will not involve a large group, so Madrid or somewhere
else nearby would be pretty easy to arrange.

d/
--
 Dave Crocker <mailto:dcrocker <at> brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
Permalink | Reply | 2 comments |
headers
JORDI PALET MARTINEZ | 5 Apr 21:23
Picon

Re: same time, different venue?

Actually if the group is not big, I believe I can manage to get both a meeting room and hotel rooms for up to
30-40 people, both in Barcelona (even in the same week as the INET).

Regards,
Jordi

----- Original Message ----- 
From: "Dave Crocker" <dhc <at> dcrocker.net>
To: "Brian E Carpenter" <brc <at> zurich.ibm.com>
Cc: "Multi6" <multi6 <at> ops.ietf.org>
Sent: Monday, April 05, 2004 8:57 PM
Subject: same time, different venue?

> Folks,
> 
> BEC> Unfortunately we can't hold the interim meeting in Barcelona. While
> BEC> it was OK for a majority of the people who responded, the local
> BEC> organizers have been unable to find a room and the situation for
> BEC> hotel rooms that week is terrible (except for those who book
> BEC> through the INET conference).
> 
> 
> Since the Barcenlona INET time and venue were ok for participants, and
> the problem was "merely" with site logistics, what about holding the
> meeting elsewhere, but nearby, at the same time (or a day earlier, so
> as not to conflict with the first day of the INET conference?
> 
> Presumably this will not involve a large group, so Madrid or somewhere
> else nearby would be pretty easy to arrange.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian E Carpenter | 6 Apr 10:16
Picon
Favicon

Re: same time, different venue?

Sorry folks, we are way beyond that decision point.

(Also, my experience of interim meetings suggests that 30-40 people
is too low.)

I do intend to summarize the responses received re dates in June shortly.

   Brian

JORDI PALET MARTINEZ wrote:
> 
> Actually if the group is not big, I believe I can manage to get both a meeting room and hotel rooms for up to
30-40 people, both in Barcelona (even in the same week as the INET).
> 
> Regards,
> Jordi
> 
> ----- Original Message -----
> From: "Dave Crocker" <dhc <at> dcrocker.net>
> To: "Brian E Carpenter" <brc <at> zurich.ibm.com>
> Cc: "Multi6" <multi6 <at> ops.ietf.org>
> Sent: Monday, April 05, 2004 8:57 PM
> Subject: same time, different venue?
> 
> > Folks,
> >
> > BEC> Unfortunately we can't hold the interim meeting in Barcelona. While
> > BEC> it was OK for a majority of the people who responded, the local
> > BEC> organizers have been unable to find a room and the situation for
> > BEC> hotel rooms that week is terrible (except for those who book
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 8 Apr 21:44
Picon
Favicon

WG Action: RECHARTER: Site Multihoming in IPv6 (multi6)

The charter of the Site Multihoming in IPv6 (multi6) working group in
the Operations and Management Area of the IETF has been updated.
For additional information, please contact the Area Directors
or the working group Chairs.

Site Multihoming in IPv6 (multi6)
---------------------------------

Current Status: Active Working Group

Chair(s):
Brian Carpenter <brc <at> zurich.ibm.com>
Kurt Lindqvist <kurtis <at> kurtis.pp.se>

Operations and Management Area Director(s):
Bert Wijnen <bwijnen <at> lucent.com>
David Kessens <david.kessens <at> nokia.com>

Operations and Management Area Advisor:
David Kessens <david.kessens <at> nokia.com>

Mailing Lists:
General Discussion: multi6 <at> ops.ietf.org
To Subscribe: majordomo <at> ops.ietf.org
In Body: subscribe multi6
Archive: http://ops.ietf.org/lists/multi6

Description of Working Group:

A multihomed site is a site that has more than one connection to the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rob Austein | 11 Apr 06:00
Favicon
Gravatar

Weekly posting summary for multi6 <at> ops.ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 20.00% |    1 | 33.14% |     6697 | iesg-secretary <at> ietf.org
 20.00% |    1 | 21.90% |     4426 | brc <at> zurich.ibm.com
 20.00% |    1 | 20.00% |     4041 | jordi.palet <at> consulintel.es
 20.00% |    1 | 12.82% |     2590 | dhc <at> dcrocker.net
 20.00% |    1 | 12.15% |     2456 | sra <at> hactrn.net
--------+------+--------+----------+------------------------
100.00% |    5 |100.00% |    20210 | Total

Grunchweather Associates provides this automatic summary on an at-whim
basis at the request of the MULTI6 WG chairs.  Your mileage may vary.
We decline responsibilities, all shapes, all sizes, all colors.
If this script produces broken output, you get to keep both pieces.
Permalink | Reply | 0 comments |

Gmane