Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: rtcweb [mailto:[e-mail]] On Behalf Of Christer
> Holmberg
> Sent: Thursday, May 07, 2015 11:04 AM
> To: Ram Mohan R (rmohanr); Alissa Cooper; Martin Thomson
> Cc: [e-mail]
> Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-
> freshness-11
> 
> Hi,
> 
> >Martin¹s statement says SHOULD here and does not mandate. ICE
> >keepalives could also be used to keep the NAT state
> 
> There needs to be a good justification for a SHOULD, and consent was never
> intended for NAT keep-alives.
> 
> Also keep in mind that, with the "virtual connection" concept, there might be
> a big number of ICE connections - some of which you may never use. Why
> send consent on those, if there is no media?

ICE keepalives or consent is only required for candidate pairs selected for media, http://tools.ietf.org/html/rfc5245#section-10 mandates sending keepalives if no packet is sent on the candidate pair ICE is using for a media component for Tr seconds. STUN Binding Indication or consent can be used for keepalives.

-Tiru

> 
> Regards,
> 
> Christer
> 
> 
> 
> -----Original Message-----
> From: Christer Holmberg <[e-mail]>
> Date: Wednesday, 6 May 2015 12:23 pm
> To: Alissa Cooper <[e-mail]>, Martin Thomson
> <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Subject: Re: [rtcweb] AD evaluation:
> draft-ietf-rtcweb-stun-consent-freshness-11
> 
> >Hi,
> >
> >I don't think you need to continue doing consent because of NAT issues,
> >if you are sending normal STUN keep-alives.
> >
> >Regards,
> >
> >Christer
> >
> >-----Original Message-----
> >From: rtcweb [mailto:[e-mail]] On Behalf Of Alissa
> >Cooper
> >Sent: 2. toukokuuta 2015 2:20
> >To: Martin Thomson
> >Cc: [e-mail]
> >Subject: Re: [rtcweb] AD evaluation:
> >draft-ietf-rtcweb-stun-consent-freshness-11
> >
> >
> >On May 1, 2015, at 9:54 AM, Martin Thomson
> <[e-mail]>
> >wrote:
> >
> >> On 30 April 2015 at 17:32, Alissa Cooper <[e-mail]> wrote:
> >>> "An endpoint that is not sending any application data does not need to
> >>>   maintain consent.  However, failure to send could cause any NAT or
> >>>   firewall mappings for the flow to expire.  Furthermore, having one
> >>>   peer unable to send is detrimental to many protocols."
> >>>
> >>> It sounds like the unstated implication here is that if you are such
> >>>an endpoint, you should keep doing consent checks anyway to maintain
> >>>consent. Should that be stated explicitly, or am I misunderstanding?
> >>
> >> Can you tell that this is my text?
> >>
> >> Yep, the unspoken implication is that if you stop maintaining
> >> consent, a flow is highly likely to break.  I'm OK with making that explicit.
> >>
> >> ... .  Absent better information about the network, an endpoint
> >> SHOULD maintain consent if there is any possibility that a flow might
> >> be needed again.
> >
> >WFM
> >
> >>
> >> (Thanks for the suggestion on Sec7.  I wasn't happy with it before.)
> >
> >_______________________________________________
> >rtcweb mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >_______________________________________________
> >rtcweb mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb