RE: Public Keys to initiate IPsec.

[Christina Helbig <cbh@zyfer.com>]

Eric,
I understand that you like to setup IPSec SAs for pairs of identities
(server name, endpoint name). In my opinion, this it not what RFC 2705 means
with using IPSec for MGCP. There you need really the IP addresses to build
SAs and you get secure IP links. The next open question for me is, do you
like to secure IP packets or MGCP commands and responses? You wrote, that
the endpoint name is in the header of MGCP messages, but is the endpoint
name in the payload of every IP packet? If not, there is no way to lookup
the SA from outbound IP packets with help of this endpoint name. So, it
looks like you want to adapt IPSec to the MGCP application layer. This
should be possible, but is this "stay with accepted standards"? Please
correct me, if I understand you wrong.
Christina

> -----Original Message-----
> From: Eric Nielsen [mailto:Eric.Nielsen@sylantro.com]
> Sent: Monday, June 03, 2002 6:37 PM
> To: Stephen Kent
> Cc: 'ipsec@lists.tislabs.com '
> Subject: RE: Public Keys to initiate IPsec.
> 
> 
> Steve,
> 
> We build a call control application using MGCP.
> IPsec is the standard for securing MGCP in RFC 2705.
> The RFC says nothing about what that really means.
> 
> Our call control agent receives only MGCP on specific
> UDP ports. Each MGCP endpoint has a name, similar to
> a SIP URI. The name is the key to all actions that
> are invoked, what keys are used, etc.
> 
> The endpoint name is in the header of MGCP message,
> but I need to relate it to the secure communications.
> I cannot allow one trusted endpoint to spoof another,
> and I cannot control IP addresses for endpoint devices.
> 
> And of course, if the power goes out, I need to provide
> service to huge numbers of endpoints without spending
> all of the server's resources re-setting up security 
> associations.
> 
> Encryption is not necessary. It looks like transport 
> mode AH with aggressive mode IKE is the direction I am 
> heading. I am now trying to connect the ISAKMP id_key_id 
> parameter to my application settings. Somehow get the
> endpointname == id_key_id, use that to look up the key.
> 
> In the end, this is a multi-vendor effort, so I must stay
> within accepted standards yet meet some high performance
> and simple administration requirements.
> 
> Eric
> 
> 
> 
> 
> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Monday, June 03, 2002 3:59 PM
> To: Eric Nielsen
> Cc: 'ipsec@lists.tislabs.com '
> Subject: RE: Public Keys to initiate IPsec.
> 
> 
> Eric,
> 
> It sounds like you want to assign some name to an app that will be 
> meaningful to folks trying to reach a set of apps, and which can be 
> configured into the SPDs to the clients trying to reach the apps. 
> Presumably this is for IPsec implementations in end systems, not 
> gateways. Is there some way for a client to assert which app it is 
> trying to contact, or is the client restructed to contacting only 
> those apps that are listed in its SPD? Absent one or the other of 
> these measures it seems unlikely that IPsec can control access (from 
> the client perspective) in a meaningful way. You've explained some 
> things about mechanisms constraints, but I'm not sure I understand 
> the security goals of using Ipsec here, which makes it hard to figure 
> out what solutions might be applicable.
> 
> 
> Steve
>