Subject: Re: [RPSEC] Charter Update

From: Russ White <[email-masked]>
Date: Thu, 12 Jan 2006 08:22:35 -0500

Sorry for taking so long to get back to this.... Normal workflow 
nonsense. :-)

> I think the charter text looks OK, although the introductory sentence of 
> you message had an amusing "s" -> "d: typo :-).

:-)

> One comment about your suggestion for an additional work item:
> 
> "Mar 06 Submit initial document discussing requirements for peering
> relationship authorization and authentication mechanisms."
> 
> I think it would be appropriate to focus on the authentication and 
> integrity requirements here, rather than authorization. Presumably any 
> authorization concerns can be addressed by using the authentication data 
> for lookup in a local database, the exact nature of which might not 
> require standardization.  But, if other folks think the authorization 
> aspects of these peering relationships should be in scope, I'm OK with 
> that too.

Anyone else have an opinion? I'm fine with either wording, so we should 
just make certain we don't get some sort of "strong objection" from the 
rest of the list (?).

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

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

---

From: Pekka Savola <[email-masked]>
Date: Sun, 15 Jan 2006 13:04:22 +0200 (EET)

I wasn't participating in earlier, but I didn't find more information 
in the archives, so..

First off, could you clarify a bit what you mean by "requirements for 
peering relationship authorization and authentication mechanisms" in 
practice?  Which layer(s) are we talking about -- anything from L1 to 
L9, or..?  For example, are the administrative processes for 
establishing peering relationship in scope?  It'd very useful if you 
could expand on this a bit as I think there hasn't been a personal I-D 
to look at yet.

Nonetheless, a few doubts about adding integrity below.

> just make certain we don't get some sort of "strong objection" from the

I'm a bit hesitant to make this change, at least without additional 
qualifiers.

That is, authorization/authentication of peering relationship tries to 
answer the questions, like "which prefixes are you allowed to 
advertise on a session?" and "how do I know who you are?"

On the other hand, integrity would change the focus the question on 
"how do you ensure that the advertisement received is the same as the 
one sent?"

Ensuring integrity seems to mainly give the benefit to the advertiser 
*).  Auth* give significant benefit to the receiver.

In my opinion, these solutions seem sufficiently different that the 
requirements may be very different.  Different folks require one but 
not necessarily the other.  These approaches should not be 
fate-sharing -- as an operator, I'm not so worried about integrity at 
this point (though I wouldn't mind getting it if I wouldn't need to 
make significant compromises in other tradeoffs).

*) that's because the receiver just processes the information it 
receives: if a MITM attacker removed a prefix, the receiver wouldn't 
care and would just route to that prefix via a different path; if a 
MITM attacker added a prefix, the receiver would just discard the 
added prefix as non-authorized.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Stefan Mink <[email-masked]>
Date: Wed, 18 Jan 2006 09:18:35 +0100

Hi Pekka,

Pekka Savola wrote:
> care and would just route to that prefix via a different path; if a MITM
> attacker added a prefix, the receiver would just discard the added
> prefix as non-authorized.

this is true if there were an authorization scheme. Since there isn't one
at the moment (and I don't see one coming, this issue was discussed at
length), the receiver at least should be able to check, if the data
was indeed received as sent (i.e. data authentication - which includes
data integrity - should be used)

   tschuess
             Stefan
-- 
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Jan 2006 11:05:28 +0200 (EET)

> data integrity - should be used)

If I get what you're arguing, I think this was my point.  If we 
developed an authorization scheme, we might not necessarily need an 
integrity mechanism.  We can't develop integrity without auth* at any 
rate.

---

From: Stefan Mink <[email-masked]>
Date: Wed, 18 Jan 2006 10:22:20 +0100

Pekka Savola wrote:
> integrity mechanism.  We can't develop integrity without auth* at any rate.

exactly! My emphasize was just that the authorization issue is so
much harder to solve, that I wouldn't loosen the integrity requirement
at the moment. People will misunderstand and think that integrity is
not an issue...

   tschuess
             Stefan Mink

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Jan 2006 09:54:29 -0500

>integrity mechanism.  We can't develop integrity without auth* at 

Pekka,

Which "auth" are you referring to above: authentication or authorization?

Integrity is generally useless without some form of authentication; 
it generally is equivalent to saying " the message I received has not 
been modified since it was sent by the sender, but I have no idea who 
the sender is."

In contrast, integrity w/o authorization is OK; it is analogous to 
saying "the message is intact, I know the source (authentication), 
and now I can decide what to do with it based on whatever policy I 
(locally) choose."

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Jan 2006 13:25:24 -0500

At 1:04 PM +0200 1/15/06, Pekka Savola wrote:
>I wasn't participating in earlier, but I didn't find more 
>information in the archives, so..
>
>First off, could you clarify a bit what you mean by "requirements 
>for peering relationship authorization and authentication 
>mechanisms" in practice?  Which layer(s) are we talking about -- 
>anything from L1 to L9, or..?  For example, are the administrative 
>processes for establishing peering relationship in scope?  It'd very 
>useful if you could expand on this a bit as I think there hasn't 
>been a personal I-D to look at yet.

These are fair questions to ask, at least up to L7 :-). I would 
assume that there is always an administrative process for deciding 
which ASes with which one peers, so it does not seem like an 
appropriate topic for a technical standards WG like ours. I expect 
Russ was referring to technical security controls to enforce policies 
devised by AS operators. In that context, we are talking about 
authentication mechanisms that allow routers to (securely) identify 
one another, either as specific routers or as routers that are 
authorized representatives of a specified AS. Then the routers use 
that ID info as input to to an authorization (access control) 
mechanism, i.e., to decide if they want to peer with one another, 
based on locally configured access control policy.

>That is, authorization/authentication of peering relationship tries 
>to answer the questions, like "which prefixes are you allowed to 

It need not do that, but it could. At a minimum a router needs to 
know whether it should establish a BGP session with another router. 
Once that decision has been made, one could use ID info from the 
authentication process to filter route advertisements, but that is a 
secondary security function.

>"how do you ensure that the advertisement received is the same as 
>the one sent?"

yes, integrity does address this question, on either a pairwise basis 
(just point-to-point for the session) or on a transitive basis. I 
think in this context only the former is on the table, since the text 
focuses on the peering session.

>Ensuring integrity seems to mainly give the benefit to the 
>advertiser *).  Auth* give significant benefit to the receiver.

Integrity is a security service that is made possible by an action on 
the part of the sender, but requires verification by the receiver. 
That is not what you suggest above.

>fate-sharing -- as an operator, I'm not so worried about integrity 
>at this point (though I wouldn't mind getting it if I wouldn't need 
>to make significant compromises in other tradeoffs).

Note that integrity, absent authentication, is generally not useful, 
as I explained in a previous message. Authorization is separable from 
integrity and authentication, in principle. However, we typically 
perform authentication so that we can use the results as input to an 
authorization (access control) decision. if we fail to provide 
continuous integrity and authenticity for a session, after an initial 
authentication and authorization step, then we leave ourselves open 
to active wiretapping attacks on the session, which undermines the 
rationale for conducting the authentication and authorization in the 
first place.

>added prefix as non-authorized.

I don't follow your analysis of an attack scenario above. If a MITM 
modifies an UPDATE, it influences the routing and forwarding 
decisions made by the receiver of the UPDATE. That is an attack on 
the security of the router that received the bogus UPDATE. It may 
cause traffic to no longer flow to the peer whose UPDATE was 
modified, or it may cause more traffic to flow to that peer. Whether 
this is good or bad for the peer depends on the nature of the 
business relationship between the affected ASes.

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 18 Jan 2006 18:40:36 -0500

> These are fair questions to ask, at least up to L7 :-). I would assume 
> that there is always an administrative process for deciding which ASes 
> with which one peers, so it does not seem like an appropriate topic for 
> a technical standards WG like ours. I expect Russ was referring to 
> technical security controls to enforce policies devised by AS operators. 
> In that context, we are talking about authentication mechanisms that 
> allow routers to (securely) identify one another, either as specific 
> routers or as routers that are authorized representatives of a specified 
> AS. Then the routers use that ID info as input to to an authorization 
> (access control) mechanism, i.e., to decide if they want to peer with 
> one another, based on locally configured access control policy.

Yes, correct. The concept is simple: It appears we've come to the "end 
of our rope" with MD5, in particular. Should we produce a doc that will 
define a concencus of requirements for what is to replace MD5?

I don't know if we really need this work or not, since replacements are 
already in progress, I believe, but, that's part of the information we 
need to include to decide if this is worthwhile work or not.

:-)

Russ

- --

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jan 2006 11:47:33 -0500

At 6:40 PM -0500 1/18/06, Russ White wrote:
>...

Two observations:

	- although collisions in MD5 make it a concern for use a hash 
function with digital signatures, use of MD5 as a MAC is a slightly 
different issue. In particular, the goal of an adversary in the BGP 
context where the MD5-based MAC is used is to modify a TCP segment in 
a fashion that yields the same MAC value, or to create a new message 
with the same MAC value. I don't believe the attacks on MD5 (or 
SHA-1) can do this yet. nonetheless, I agree that the current TCP MD5 
checksum option should be replaced.

	- there are two individual I-Ds that have been published 
recently, each proposing replacement mechanisms for the TCP MD5 
checksum, including improved key management.  The community needs one 
replacement, not two.  I have reviewed both I-Ds and each has serious 
problems that need to be addressed.

I'm in favor of RPSEC making the selection of a replacement for the 
TCP MD5 checksum option a work item, it the routing ADs agree it 
should be here.

Steve

---

From: Paul Jakma <[email-masked]>
Date: Thu, 19 Jan 2006 23:55:42 +0000 (GMT)

On Thu, 19 Jan 2006, Stephen Kent wrote:

> checksum, including improved key management.  The community needs 
> one replacement, not two.  I have reviewed both I-Ds and each has 
> serious problems that need to be addressed.
>
> I'm in favor of RPSEC making the selection of a replacement for the TCP MD5 
> checksum option a work item, it the routing ADs agree it should be here.

I'm curious, why do people want to formulate yet more IP security 
hacks? We now have a standard IETF IP security and key exchange 
protocol, deployable today.

What exactly is wrong with IPSec that makes it unsuitable that can 
not be fixed? If it's really not suitable, surely at least parts of 
IPSec could be re-used? Be it on the key exchange protocol side (IKE) 
or else on the IP processing side (AH ip opt).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Alimony is the high cost of leaving.

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jan 2006 20:01:39 -0500

>>     - there are two individual I-Ds that have been published recently, 
>> each proposing replacement mechanisms for the TCP MD5 checksum, 
>> including improved key management.  The community needs one 
> I'm curious, why do people want to formulate yet more IP security hacks? 
> We now have a standard IETF IP security and key exchange protocol, 
> deployable today.
> 
> What exactly is wrong with IPSec that makes it unsuitable that can not 
> be fixed? If it's really not suitable, surely at least parts of IPSec 
> could be re-used? Be it on the key exchange protocol side (IKE) or else 
> on the IP processing side (AH ip opt).

A large segment of the routing community believes IPsec is too 
heavyweight (me among them), and isn't suited for the multicast 
environment most routing protocols operate in.

:-)

Russ

- --

---

From: Paul Jakma <[email-masked]>
Date: Fri, 20 Jan 2006 01:47:06 +0000 (GMT)

On Thu, 19 Jan 2006, Russ White wrote:

> heavyweight (me among them),

What specifically?

And 'large segment' is a fairly bold claim too.

> and isn't suited for the multicast environment most routing 
> protocols operate in.

That's seems a red-herring. The multicast protocols already are using 
statically keyed HMACs anyway. Which leaves BGP, which uses TCP - not 
exactly multicast.

The IPSec AH side of things /can/ be used in multicast, if I remember 
correctly. That leaves the key distribution side - a problem being 
worked on I thought (for IKE). The other alternative is to use an 
in-protocol key distribution mechanism, but again that shouldn't 
preclude using AH (which is what is being vaguely considered for 
OSPF, iirc).

What indisputable/immovable reasons are there to go off and reinvent 
IPSec (with the real risk of doing so poorly)?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
You are going to have a new love affair.

---

From: Merike Kaeo <[email-masked]>
Date: Fri, 20 Jan 2006 02:37:35 -0800

OK.  Since this is something I've been wondering about  I'll chime 
in.......

Most router (and other)  IPsec configurations are fairly horrible and 
from my experience (configuring at least 20 different implementations 
in last 8 years and doing some testing 3 years back to see how 3 
varying large router vendors dealt with IPsec interoperability) one 
major problem is operational deployment headache which (in my ever 
optimistic mind) can be fixed by:

- same defaults for most IPsec choices [i.e. use esp w/null encryption 
and SHA-1]
- have no more than 4 configuration lines [yes, this can be done]  
hint: 1. state routing protocol; 2. state using  IPsec and with which 
neighbor; 3. state how you want to authenticate Diffie-Hellman exchange 
(let's assume pre-shared key); 4. define pre-shared key

This gives you similar config as with the MD-5 authentication today but 
you get added benefit of 'new' keys used for authentication algorithm 
(let's say SHA-1) which are periodically 'refreshed'.

Is the processing overhead really that intensive when using IKE and esp 
w/null encryption that IPsec is a non-starter?  Dave Ward had a draft a 
few years back on securing BGP using IPsec and I had asked him to 
resurrect it 2 years ago.......mainly to get an authentication 
mechanism deployable where keys were not static for years :)  There was 
no interest then in that work which I thought too bad.  But maybe I'm 
not understanding some subtle (or maybe more obvious) issue in terms of 
actual implementation and performance.  And I would really love to hear 
the technical justifications so that I can put the matter to rest in my 
mind.

There's a draft defining how OSPFv3 should do authentication and it is 
defining ESP w/ null encryption as a MUST and AH as a SHOULD.  
Automated key management is not mandated due largely to multicast 
issues but I also thought some of those issues were being addressed and 
worked on.

- merike

On Jan 19, 2006, at 5:47 PM, Paul Jakma wrote:

>> and isn't suited for the multicast environment most routing protocols 
>> operate in.
>
> preclude using AH (which is what is being vaguely considered for OSPF, 
> iirc).
>

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 20 Jan 2006 10:22:52 +0100

----- Original Message -----
From: "Paul Jakma" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>; "Russ White" <[email-masked]>
Sent: Friday, January 20, 2006 12:55 AM
Subject: Re: [RPSEC] Charter Update

> protocol, deployable today.
We have several.  We are moving away from the 'every application must do it in
its own way' exemplified by OSPFv2, BGP4 and SNMPv3 to use a standard approach
at a lower layer.  Yes, we have a standard at layer 3 but we also have, at layer
4, SSH and TLS competing for market share.  SNMP has now chosen the SSH approach
for good reason, BGP might do the same

I think it important to move away from the former approach simply because
security needs to be updated as and when it is breached and that is in general
not in synch with the needs to update the application, so security and
application need decoupling.  And, within any security, as in those I mention
above, it is necessary to be able to slot in new algorithms as and when an
algorithm becomes too weak for its purpose.  So replacing MD5 in BGP with SHA-1
or SHA-256 would, for me, be totally wrong.

Tom Petch

<snip>

---

From: Paul Jakma <[email-masked]>
Date: Fri, 20 Jan 2006 13:08:16 +0000 (GMT)

On Fri, 20 Jan 2006, Tom Petch wrote:

> We have several.  We are moving away from the 'every application 
> must do it in its own way' exemplified by OSPFv2, BGP4 and SNMPv3 
> to use a standard approach at a lower layer.

Laudable.

> Yes, we have a standard at layer 3 but we also have, at layer 4, 
> SSH and TLS competing for market share.  SNMP has now chosen the 
> SSH approach for good reason, BGP might do the same

Neither SSH nor TLS could work for BGP, as neither would protect the 
TCP session.

> I think it important to move away from the former approach simply 
> because security needs to be updated as and when it is breached and 
> that is in general not in synch with the needs to update the 
> application, so security and application need decoupling.

Yes, I agree. Hence why I really do not see why we should we invent 
another IPSec-alike to replace TCP-MD5 for BGP.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
He is truly wise who gains wisdom from another's mishap.

---

From: Russ White <[email-masked]>
Date: Fri, 20 Jan 2006 10:19:42 -0500

> What specifically?

I think Merike answered that one well, so I'll leave it for the moment.

> And 'large segment' is a fairly bold claim too.

Well, I talk to a lot of people about these things.... :-)

> statically keyed HMACs anyway. Which leaves BGP, which uses TCP - not 

The original proposed charter statement is that we should devise a set 
of requirements, not necessarily a solution. I actually think we could 
go to the point of "everything but the transport" in this case, but the 
original concept was requirements.

> preclude using AH (which is what is being vaguely considered for OSPF, 

Can IPsec be used IS-IS? No.... Can IPsec handle the unicast/multicast 
nature of OSPF, really? Most people don't realize that OSPF and IS-IS 
(and every other IGP other than RIP) use a mix of unicast and multicast 
on a single link, even a single link type, under varying conditions. I 
don't know that we want to set up a single IPsec session for multicast 
from every router to every router (multicast) and then a full mesh of 
IPsec sessions on a single link to handle the unicast routing traffic. 
IMHO, that's a lot of a overhead (see the "too heavy" comment above).

It seems like replacement suggestions are moving forward without anyone 
actually looking at the requirements--is there a need to look at the 
requirements in these situations, and make recommendations?

:-)

Russ

- --

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Jan 2006 10:37:39 -0500

At 8:01 PM -0500 1/19/06, Russ White wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>

We're talking about BGP peering sessions, which take place over TCP. 
The proposals I noted are for TCP session authentication, primarily 
in support of BGP session protection. TCP does not support 
multicast. Why do you mention multicast above? It seems irrelevant to 
this discussion.

Steve

---

From: Blaine Christian <[email-masked]>
Date: Fri, 20 Jan 2006 07:52:13 -0800

On Jan 20, 2006, at 7:37 AM, Stephen Kent wrote:

>>>> recently,

I believe identifying preferences for key management belongs in this  
group.  It is called out in the BGP rpsec draft as an issue to be  
addressed.

---

From: Blaine Christian <[email-masked]>
Date: Fri, 20 Jan 2006 07:55:53 -0800

My .02

>> environment most routing protocols operate in.

IPSec is a pain in the rear to configure and manage.  MD5 is very  
easy but the key management methods currently available stink.

> We're talking about BGP peering sessions, which take place over  
> TCP. The proposals I noted are for TCP session authentication,  
> primarily in support of BGP session protection. TCP does not  
> support multicast. Why do you mention multicast above? It seems  
> irrelevant to this discussion.

Have to agree here...  Not sure what is meant by the multicast comment.

---

From: Russ White <[email-masked]>
Date: Fri, 20 Jan 2006 11:18:05 -0500

>> in support of BGP session protection. TCP does not  support multicast. 
>> Why do you mention multicast above? It seems  irrelevant to this 
>> discussion.

> Have to agree here...  Not sure what is meant by the multicast comment.

Is RPsec limited to BGP? I didn't realize it.... :-)

Is OSPF multicast, and used a lot? I thought so.... Is IS-IS multicast, 
and used a lot? I thought so... Maybe I'm just living in an alternate 
universe, and in the real world, BGP is the only routing protocol 
actually used by anyone (?).... <hehe>

:-)

Russ

- --

---

From: Paul Jakma <[email-masked]>
Date: Fri, 20 Jan 2006 16:29:31 +0000 (GMT)

> I think Merike answered that one well, so I'll leave it for the moment.

I read his reply as being mostly in support of using IPSec.

> Well, I talk to a lot of people about these things.... :-)

Undoubtedly. ;)

How many of the concerns people in the community whom you talk you 
are related to the actual protocol though, rather than 
implementation?

> Can IPsec be used IS-IS? No....

Well, why not?

> Can IPsec handle the unicast/multicast nature of OSPF, really?

Yes, why couldn't it? There's even a draft to replace the in-protocol 
HMAC with IPSec for v3.

> link, even a single link type, under varying conditions. I don't 
> know that we want to set up a single IPsec session for multicast 
> from every router to every router (multicast) and then a full mesh 
> of IPsec sessions on a single link to handle the unicast routing 
> traffic. IMHO, that's a lot of a overhead (see the "too heavy" 
> comment above).

Urg, I'd agree if were like that. It isn't AIUI.

> It seems like replacement suggestions are moving forward without 
> anyone actually looking at the requirements--is there a need to 
> look at the requirements in these situations, and make 
> recommendations?

regards,
It's stuck in the Web.

---

From: Russ White <[email-masked]>
Date: Fri, 20 Jan 2006 11:58:32 -0500

> How many of the concerns people in the community whom you talk you are 
> related to the actual protocol though, rather than implementation?

Both.

>> Can IPsec be used IS-IS? No....

Hmmm... Because IS-IS doesn't run on top of IP??

:-)

Russ

- --

---

From: Paul Jakma <[email-masked]>
Date: Fri, 20 Jan 2006 17:09:29 +0000 (GMT)

> Hmmm... Because IS-IS doesn't run on top of IP??

Ah, sorry, I don't follow IS-IS. I thought there was an effort 
underway to encapsulate IS-IS in IP and that you were referring to 
that.

ISO IS-IS obviously isn't going to benefit from anything done in the 
IP space. So again that seems a red-herring, if that's what you refer 
to.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
All generalizations are false, including this one.
 		-- Mark Twain

---

From: Russ White <[email-masked]>
Date: Fri, 20 Jan 2006 12:13:06 -0500

> Ah, sorry, I don't follow IS-IS. I thought there was an effort underway 
> to encapsulate IS-IS in IP and that you were referring to that.
> 
> ISO IS-IS obviously isn't going to benefit from anything done in the IP 
> space. So again that seems a red-herring, if that's what you refer to.

So, you consider it "not worth worrying about?" Or??? Why shouldn't we 
investigate the requirements for solutions that would fit both in the 
IS-IS and OSPF spaces? Or, are you saying that IPsec works for OSPF 
(which I'm not positive I agree with yet, nor that even if it works, 
most network operators would agree it's the ideal or best solution), 
there's no reason to look at requirements, because the only protocol 
left is IS-IS? Or... (?)

:-)

Russ

- --

---

From: Paul Jakma <[email-masked]>
Date: Fri, 20 Jan 2006 17:33:20 +0000 (GMT)

On Fri, 20 Jan 2006, Russ White wrote:

> So, you consider it "not worth worrying about?" Or???

I didn't say that.

> Why shouldn't we investigate the requirements for solutions that 
> would fit both in the IS-IS and OSPF spaces?

Is it possible to specify an L3 transport authentication mechanism 
that could be common to both? If you think it is, fair enough, fire 
away. I would have thought it might be difficult.

If you mean more general key certificate infrastructure, x.509, 
whatever - sure.

> Or, are you saying that IPsec works for OSPF (which I'm not 
> positive I agree with yet, nor that even if it works, most network 
> operators would agree it's the ideal or best solution), there's no 
> reason to look at requirements, because the only protocol left is 
> IS-IS? Or... (?)

Let me restate the question, I didn't realise ISO L2 was going to be 
dragged into it:

What good reason is there to not use IPSec to protect IP transported 
routing protocols?

Even more specifically, what good reason is there to replace TCP-MD5 
with anything other than IPSec?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
excessive collisions & not enough packet ambulances

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Jan 2006 15:09:38 -0500

>Is RPsec limited to BGP? I didn't realize it.... :-)

As you may have noted from other comments on your message, the thread 
was dealing explicitly with the candidate replacements for the TCP 
MD5 option, not network or transport layer security for all routing 
protocols.  I feel pretty confident about that since it was my 
message to which you responded.

>actually used by anyone (?).... <hehe>

You appear to be living in a universe where the topic of a thread is 
easily lost.  Maybe you need duck tape in your universe. :-)

Steve

---

From: Russ White <[email-masked]>
Date: Fri, 20 Jan 2006 16:47:45 -0500

> easily lost.  Maybe you need duck tape in your universe. :-)

Or, perhaps, I'm not the one who lost the topic of the thread. The 
original charter item under discussion was:

Mar 06 Submit initial document discussing requirements for peering
relationship authorization and authentication mechanisms.

I don't see BGP in there. The original intent was to produce a 
requirements document for peering authorization/authentication 
requirements for all protocols, since the requirements should be fairly 
common among them.

But, the scope, number of docs, whether this was useful work, etc, was 
where the original discussion started.

:-)

Russ

- --

---

From: Pekka Savola <[email-masked]>
Date: Sat, 21 Jan 2006 14:48:46 +0200 (EET)

On Fri, 20 Jan 2006, Paul Jakma wrote:
...
> Yes, I agree. Hence why I really do not see why we should we invent another 
> IPSec-alike to replace TCP-MD5 for BGP.

FWIW, I agree with this.  TCP-MD5, especially in years to come, is not 
a perfect solution for BGP.  It probably isn't even a "good" solution. 
But is it a sufficient solution, given other mechanisms (e.g., GTSM) 
that exist?

In my opinion, yes.  If you're worried about attacks on the link [1], 
you'll want to use something strong, and I'd recommend considering 
IPsec, not reinventing it.  If you're worried about attacks from 
outside the link, you can use stuff like ingress filtering, proper 
ICMP error verification and/or GTSM to complement TCP-MD5.  Heck, you 
may not even need to use TCP-MD5 at all.

The original goal of TCP-MD5 was to create a simple solution. 
Reinventing IPsec to replace it might or might not end up being 
"simple (enough)" but nonetheless I'm puzzled why doing so would make 
sense.

[1] TCP-MD5 (or something like that) is really only needed when you 
have multiple sessions over an internet exchange, and you want to 
protect the session from deliberate attacks from the other exchange 
members' peering routers. In the exchanges we participate at, we don't 
see this as a significant threat.  Other mechanisms (ingress 
filtering, GTSM) can deal with all the other major usage scenarios.

---

From: "Dan B" <[email-masked]>
Date: Sun, 22 Jan 2006 11:49:58 +1100

I agree,,,,,

dan bernardo
information security officer
dept of commerce, nsw, australia

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "Paul Jakma" <[email-masked]>
Cc: <[email-masked]>; "Tom Petch" <[email-masked]>; "Stephen
Kent" <[email-masked]>; "Russ White" <[email-masked]>
Sent: Saturday, January 21, 2006 11:48 PM
Subject: [RPSEC] no TCP-MD5 replacement please

> > Yes, I agree. Hence why I really do not see why we should we invent
another
> _____________________________________________________
> This mail has been virus scanned by Australia On Line
> see http://www.australiaonline.net.au/mailscanning
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Jan 2006 12:26:35 -0500

Russ,

>-...

Sorry, Russ, I was viewing the thread as being rooted at the messages 
last Wednesday, where I responded to Pekka, and you concurred, saying

	"Yes, correct. The concept is simple: It appears we've come to the "end
	of our rope" with MD5, in particular. Should we produce a doc that will
	define a concencus [sic] of requirements for what is to replace MD5?"

However, the thread with the original Subject of "Charter Update" 
dates back to 12/1/05, when you suggested broadening the charter via 
the bullet you cited above. That bullet was not specific to BGP, but 
since that message was 6 weeks prior to the current discussion, and 
given your more recent comment about what we were discussing (as 
quoted above), I think most of us assumed that the more recent, 
BGP-focused comment you made was what we were discussing now. Hence 
the multi-cast vs. unicast confusion.

Going forward I think the original bullet is too broad and should be 
replace by protocol-specific bullets. It seems rather ambitious to 
call for even an initial document addressing authorization and 
authentication for all IETF routing protocols in two months.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Jan 2006 14:21:42 -0500

Pekka,

I think your message states the important criteria, i.e., if an ISP 
is not concerned about on-link attacks, then GTSM, ingress filtering, 
and ICMP security measures are probably sufficient. However, when 
on-link attacks are a concern, we need a suitable replacement for the 
TCP-MD5 option.  (I would not include the qualification "... 
deliberate attacks from the other exchange members' peering routers." 
The attacks could be launched by any device with access to the links 
via which the peering takes place.)

 From a standards perspective, our goal should be to develop standards 
that give the operators the necessary standards from which to choose, 
based on their perception of the threat. I take Paul's messages to be 
in that spirit when he suggests we consider IPsec as an alternative 
to replacing the TCP-MD5 option with a similar option that updates 
the algorithms and improves key management.

Steve

---

From: David Ward <[email-masked]>
Date: Mon, 23 Jan 2006 15:28:51 -0600

All -

In the past I wrote a draft on how to run BGP w/ IPsec. There are
effectively no protocol changes required. If we want it dusted off and
republished, I can revisit it. Note that there is no magical golden ring
that one obtains by running BGP over IPsec but, it can easily be done and
written as a BCP, informational ...

-DWard