Re: [MMUSIC] Review of draft-saito-mmusic-sdp-ike

[Makoto SAITO <ma.saito at nttv6.jp>]

Hi Richard and Dean,
Thank you for your comments.

As Dean pointed, it will be a decisive reason of using SIP
that SIP is the most effective way to launch the NAT-T mechanism.
I don't see any reasons not to use SIP to establish IPsec in this
situation (although the current draft only specifies the NAT-free
cases).

By the way, I also believe it is a big advantage to delegate
authentication to 3rd party (sip proxy) very easily by just riding
existing SIP infrastructure and SIP-identity mechanism.
I may also have to look closely at BTNS works as Richard said,
but I think using finger print of self-signed cert endorsed by
SIP-Identity is fairly simple way because your application only
keeps the faithful fingerprint for the following IKE authentication.
Of course, we need to brush-up the technical details not mentioned
in the current draft, so it is very helpful to dig down the details.


--
Makoto Saito


Dean Willis wrote:
> On Aug 13, 2007, at 1:17 PM, Richard Barnes wrote:
>
> > Draft:  draft-saito-mmusic-sdp-ike-01
> > Reviewer: Richard Barnes
> > Review Date: 13 Aug 07
> >
> >
> > General Comments:
> > ------------------------------------------------------------------------
> > 1. This document seems to be doing two things: (1) Using SDP carried 
> > in SIP to initiate an IKE session, and (2) Defining how SIP Identity 
> > can be used in lieu of IKE authentication.
>
> I think you're looking at the side-effects, not the central theme. And 
> I'm not sure the draft really brings the central them into clear focus.
>
> The question to ask is "Why do people want to use SIP to establish an 
> IPSEC SA"?
>
> And the answer, I think, has to do with:
>
> 1) SIP's utility as a cross-nat rendezvous mechanism. We currently don't 
> have any other good way for node A, which is behind a NAT, to find and 
> establish communication with node B, which is also behind a NAT. Much of 
> the complexity of SIP, including "ice", "outbound", and "gruu", is 
> involved in solving this problem. This is a very difficult problem to 
> solve, and many communications modalities suffer from it. Having solved 
> it in SIP, we can expect to see attempts to use SIP to bootstrap a 
> solution to all those communication modalities.
>
> 2) SIP's extension of the domain namespace to include "user parts", 
> allowing more flexible addressing that includes subaddressing at a given 
> host without burning more IP address space.
>
> Of course, one might argue that we'd have a cleaner model if we replaced 
> many of these SIP graft-ons with a transport protocol that handles them 
> transparently and independently from the application. We've started 
> talking about ways to do that in P2PSIP. But for now, SIP is the only 
> hammer we have that appears to succeed in driving this kind of nail.
>
> --
> Dean
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic