Subject: Re: [RPSEC] Draft Status....

From: "Senthilkumar Ayyasamy" <[email-masked]>
Date: Mon, 22 Jul 2002 23:06:21 -0500

>you should document the practices of BGP/TCP+MD5 checksums
>and BGP/TCP/IPSEC.
  what you are telling is a solution. But we are here to define the problem 
space and requirements.

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Gregory Lebovitz <[email-masked]>
Date: Wed, 24 Jul 2002 18:22:07 -0700

Though not an authority on this topic at all, I did sit in on the MBONED WG
last week, and heard pretty clearly that MSDP, currently at draft 13, was
going to be pushed forward at the draft 6 version. It sounded like draft 6
really doesn't address a lot of the features/requirements people hoped for
out of MSDP. I took from the discussion that maybe MSDP was not going to be
used much in the wild. If I understood this clearly, I would not include it
on the list. 

Can anyone with closer ties to MSDP, and its future, comment more
authoritatively? 

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]]
Sent: Wednesday, July 24, 2002 9:02 AM
To: Gregory Lebovitz; 'Alex Zinin'; [email-masked]
Subject: Re: [RPSEC] Draft Status....

Brian Haberman wrote:
> 
> Gregory Lebovitz wrote:
> >
> > [gregory]Here is a list to start, and is intentionally NOT
comprehensive, so
> > please chime in with agreement/disagreement:
> > ==v4==
> > - OSPF
> > - BGP
> > - IS-IS
> > - PIM-SM
> > - RIP
> > ==v6==
> > - RIPng
> > - OSPFv3
> > - BGP
> 
> PIM-SM supports IPv6 as well.  I would not include DVMRP and MOSPF gets
> carried along with OSPF.

I just had one more thought.  Should MSDP be included in this list?

Brian

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Jul 2002 21:14:44 -0400

Folks,

Although it is certainly possible to discuss routing protocol 
vulnerabilities based on the specific transport protocols that are 
employed, I'd like to suggest  a slightly different tact.

Over time I think the IETF has evolved to adopt a threat model that 
assumes man-in-the-middle attacks. We have some protocols that were 
designed with a more limited threat model, one that did not admit 
such attacks, and this has proven to be a mistake.

If we assume that man-in-the-middle attacks are a valid concern, then 
the details of the underlying transport protocol probably do not 
matter much, since we will require a crypto-security mechanism to 
protect the traffic. It also is appropriate to document the ways in 
which a routing protocol relies on the underlying transport protocol.

I don't think that documenting vulnerabilities of otherwise 
unprotected transport protocols is the best strategy for our work.

Steve

---

From: "Michel Py" <[email-masked]>
Date: Wed, 24 Jul 2002 20:33:25 -0700

>>> Brian Haberman wrote:
>>> I would not include DVMRP

>> Michel Py wrote:
>> Could you briefly explain why you would not include DVMRP?

> Brian Haberman wrote:
> Sure.  DVMRP is not going anywhere.  It has been superceded by
> PIM, both SM and DM.  There has been little, to no interest ever
> expressed in trying to "protect" the DVMRP protocol while there
> has been at least two proposals to secure PIM.
> There has been at least one mention of making DVMRP historic
> when/if it ever gets past the IESG.

Fair enough.

> With PIM, some of the message exchanges on the wire occur to
> indicate that there is a host interested in a particular group.
> The message exchange identifies a receiver and causes the creation
> of forwarding state in the routers.  In unicast, the message
> exchanges do not identify receivers.  So, Senthil's question is
> whether or not the differences between those types of messages are
> great enough that there is actually a different threat model for
> routing and forwarding.

Without debating the topic itself, please do not associate it with
unicast and/or multicast. The protocol I am developing (MHAP) is a
unicast protocol but does use rendezvous points; parts of it are somehow
similar to PIM.

Michel.

---

From: "Senthilkumar Ayyasamy" <[email-masked]>
Date: Thu, 25 Jul 2002 04:34:00 -0500

I must accept your views at this point. The whole
process of routing in MPLS architecture depends
on traditional IGP schemes. I am not a MPLS expert
but i see some people in the list have interest
in  security in MPlS. But security wrt to MPLS
arch is itself in infant stage. Hence, they should
see if any new st&r are introduced in mpls environment
other than normal  IGP st&r.

>Focusing the efforts is essential for making progress,
>especially at this stage.
So,It is better to keep MPLS out of scope at this stage.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---

From: "Michel Py" <[email-masked]>
Date: Thu, 25 Jul 2002 22:16:43 -0700

> Russ white wrote:
> [the onion thing]
> And I hope my example is not too absurd to blow your
> thinking cap off.

IMHO, a very good parabole.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 30 Jul 2002 12:46:26 -0700

Russ,

> Russ White wrote:
> Let's say this: I'm not quite certain where you come up
> with 1 billion (could you articulate it?),

It's the consensual number for the ipv6mh design target. More
specifically, the consensus is that 1 Billion independent multihomed /48
prefixes are the smallest number that has not been challenged as being
too small.

Trying to stay brief, MHAP deals with two kinds of prefixes:
(Prefixes are /48s for end-sites)
- Centralized.
- Geographically aggregatable.

We were actually able to fit 2.5 billion geo prefixes (instead of the 1
billion target) in a /16 because of a higher than expected HD ratio,
which takes us roughly to the point where every 4-person household has
their /48 prefix.

Interestingly, I also put a cap of 1 million centralized prefixes (which
are targeted to large, multinational, multihomed organizations) and I
was told that it was not enough by many people.

Given the fact that they are ~15k multihomers today, I hope that gives
you an idea of what kind of magnitude changes we have to deal with when
designing IPv6 routing protocols.

> but I do agree that larger numbers are in the coming in the
> future, and we have no idea how the current routing protocols
> will react to them.

There is a more generic issue: even if you can manufacture a router that
has enough CPU and memory to handle a billion routes, do we want to go
that way? What a pain in the kazoo it would be to maintain /
troubleshoot with BGP as we know it today.

> The ipv6 folks tell me that the routing table sizes should
> not change that radically, because we will be summarizing
> in a radical way.

It depends on which ipv6 folks you are talking to. There are a number of
people that think that we can follow Moore's law and keep building more
powerful hardware.

> I always ponder that there are 4.2 billion addresses in a
> /32, which is what I understand the registries are currently
> handing out, and I'm hoping that summarization truly is radical.

Note that I don't drill down that deep. To me, a /32 is 64K /48
prefixes, not 4B /64 subnets.

The 2.5 billion (which is 4 billion less overhead) I am dealing with are
4 billion of /48s. The SLA bits (bits 48 to 63, which are the subnets
specific to each site) are negotiated between sites only and not on the
global routing table. That would be 256 trillion prefixes, too much.

Michel.