Subject: [IPTEL] RE: A plea for help from the iptel working group

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Nov 2000 18:32:34 -0500

I'm personally okay with that. 

I think that TRIP is sufficiently close to BGP in this regard, that the
security that works there should  work here too.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, November 21, 2000 2:21 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'
> Subject: A plea for help from the iptel working group
> 
> 
> 
> Jonathan,
> 
> Maybe this is irrelevant since the draft deadline
> passed, but I predictably am in favor of avoidance
> of problems that cry out for public key solutions
> unless there is some absolute and unavoidable
> reason why they are necessary. If this were BGP,
> I would be *very* concerned about the implications
> of the number of public key signatures and
> verifies. However, TRIP is not BGP, so it's hard
> for me to guage whether it's unavoidable or not.
> 
> Maybe it really would be the better part of valor
> to leave it out until we have some operational
> experience?
> 
> 			Mike
> 
> Jonathan Rosenberg writes:
>  > Folks,
>  > 
>  > There is only one remaining open issue with TRIP
>  > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-03.txt
>  > 
>  > and it is one that the authors cannot resolve without assistance.
>  > 
>  > THe issue is authentication for attributes. The authors 
> think that this
>  > feature is still useful. However, we need to have a set of 
> algorithms, and a
>  > specific encoding format for those algorithms, to be 
> included in the spec. I
>  > believe that this authentication encoding will need to include the
>  > certificate for the signer, since an LS may not have a pre-arranged
>  > relationship with the originator of a route.
>  > 
>  > We need help in coming up with a set of algorithms (we 
> suspect DSA and RSA,
>  > but need additional guidance on what more, if anything, 
> needs to be said)
>  > and their encoding, including the certs, within TRIP. 
> Actual text for
>  > inclusion in the draft is specifically what we want, not 
> suggestions like
>  > "check out protocol foo", since invariably, what protocol 
> foo has isn't
>  > quite right (i.e., uses ASN.1 or XML or something we don't have). 
>  > 
>  > So, this is a PLEA for assistance. 
>  > 
>  > If someone cannot contribute some text here, we may be 
> forced to remove this
>  > feature all together in the baseline draft, and relegate 
> it to a separate
>  > I-D. That may or may not go over well with the A-Ds either.
>  > 
>  > Thanks,
>  > Jonathan R.
>  > 
>  > ---
>  > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
>  > Chief Scientist                             First Floor
>  > dynamicsoft                                 East Hanover, NJ 07936
>  > [email-masked]                     FAX:   (973) 952-5050
>  > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
>  > http://www.dynamicsoft.com
>  >  
>  > 
> 

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 21 Nov 2000 20:39:01 -0500

> security that works there should  work here too.

It is also not clear that just signing or otherwise authenticating
requests is particularly helpful. If flybynight.com advertises 1c to
anywhere in the world, they may well have a certificate proving that
they are indeed flybynight.com. Thus, I suspect that people will limit
who they listen to, apply some sanity checks to catch errors (which no
amount of signing and crypto can prevent) and use TLS or IPsec to secure
the peer relationships if they are worried about the links. (Since most
of the information is at least semi-public, it's not even clear that
this is particularly urgent.)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs