Subject: [Sip] Version 01 of sec-agree just released

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 14 May 2002 10:07:44 +0300

Hello,

We have just released a new version of the security agreement draft.
Until it appears in the archives, you can fecth it from:

http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-sec-agree-01.txt

We have incorporated all the feedback that we received during the
interim meeting in Las Vegas. The syntax has been fixed and now it
follows the general syntax for SIP extensions.

We have also narrowed down the scope of the draft. Now it only solves
the security negotation between the UA and the first-hop proxy. Thanks
to this limitation in the scope of the solution, we have been able to
remove any URI, host name or IP address in the security header fields
(the old and controversial to and from parameters within these header
fields). 

We have also added a couple of examples that illustrate the use of the
mechanism described in the draft.

As usual, feedback on this document is appreciated.

Best regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jari Arkko <[email-masked]>
Date: Fri, 31 May 2002 23:09:55 +0300

Hi,

I'm working on an informational document (draft-ietf-ipv6-cellular-host-02.txt)
that discusses some issues related to IPv6 implementation on mobile
terminals.

IPv6 has a function for Neighbour Unreachability Detection (NUD, RFC 2461).
The purpose of this function is to ensure that the nearest neighbour,
typically the router, is up and running. This check is normally done at
the IP layer, by sending a Neighbour Solicitation message and getting back
a Neighbour Advertisement message.

However, these messages are sometimes unnecessary if some upper layer
already knows that we have connectivity. RFC 2461 specifies that the
reception of a TCP acknowledgement for something that we have sent
recently shows that we have connectivity to the peer, and consequently,
to the router. Note that it isn't enough to see that we are *receiving*
packets, we need to know if the packets we *sent* are getting through.
Note also that any upper-layer advise to IPv6 is purely a local
optimization and optional.

Unfortunately, the TCP ACK scheme doesn't work with UDP, and this might
lead to sending some unnecessary NS/NA messages when SIP and RTP traffic is
running over UDP. As bandwidth usage on cellular environments is pretty
critical, we'd like to do something about it. I've been asked to
describe whether some typical cellular host applications can provide
such feedback. And here's why I come to you, given that SIP and RTP-based
IP traffic is a one of the major applications.

My first question is if RTCP can provide the information. Does this
work. (Yeah, I know its the wrong group but I'm subscribed here
and I'm sure you know the answer.)

       When UDP is used for transporting RTP, the RTCP
       protocol feedback should be used as a basis for
       the reachability confirmation. If an RTCP
       packet is received with a reception report block
       indicating some packets have gone through, then packets
       are reaching the peer. If they have reached the
       peer, they have also reached the neighbour.

The second question is if SIP can provide the information. Does this
work:

       When UDP is used for transporting SIP, responses to
       SIP requests should be used as the confirmation that
       packets sent to the peer are reaching it. When the
       host is acting as the server side SIP node, such
       confirmation is generally not available. However,
       a host may interprete the receipt of a SIP ACK request
       as confirmation that the previously sent response
       to a SIP INVITE request has reached the peer.

Thanks,

Jari