RE: [SAFE] RE: [BEHAVE] BOF request under consideration: SAFE

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Philip Matthews [mailto:[e-mail]] 
> Sent: Friday, October 12, 2007 5:06 AM
> To: <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [SAFE] RE: [BEHAVE] BOF request under consideration: SAFE
> 
> I would like to second Markus comments: I also support the goals of  
> the BOF, but I share his two technical concerns. The second concern  
> was raised at the "informal BOF" in Chicago, but the first concern I  
> have not hear discussed before.
> 
> Regarding the first concern, I think this might actually go beyond  
> just STUN Control to be a general STUN/ICE issue.  Even without STUN  
> Control, it seems important for an endpoint to know if its 
> keep-alive rate is sufficient to keep the bindings in intermediate 
> NATs alive.  The way I see this might be done is for the STUN server 
> (or perhaps the remote endpoint) to send data at regular intervals 
> while the client sends keep-alives at some rate. If the client 
> continues to receive data after one or two keep-alive intervals have 
> passed, the client knows its keep-alive rate is sufficient.  A client 
> may choose to test a lower keep-alive rate in this manner to see 
> if that is also sufficient.

Teredo (Section 5.2.7 of RFC4380, 
http://tools.ietf.org/html/rfc4380#section-5.2.7) has a documented
procedure for doing what you describe.

-d

> - Philip
> 
> On 11-Oct-07, at 08:53 , <[e-mail]>  
> <[e-mail]> wrote:
> 
> > Hi,
> >
> > I support the goals of this BOF and I believe in the reasoning  
> > provided
> > by the charter. I have two concerns that should be 
> addressed before I
> > think STUN NAT control could become successfully deployed:
> >
> > 1. Technical issue: STUN control allows a host/application 
> to discover
> > NATs and disover/set NAT binding timers for UDP (typically to higher
> > values than what the defaults, perhaps around 30-300 s, would be).
> > However, BEFORE the application can start using the increased  
> > keepalive
> > period, it needs to have a some sort of assurance that there aren't
> > OTHER middleboxes on its path with lower keepalive values.  
> > Otherwise it
> > would be impossible to rely on the increased timer values, 
> and thus  
> > the
> > whole mechanism might fail in practice. So, I would like to 
> include in
> > the charter a goal where such discovery mechanisms and their
> > applicability are considered. The actual mechanism might be based on
> > STUN or something else. I know this is a hard problem in general,  
> > but in
> > many access network topologies the problem can be solved by
> > configuration + discovery. I'd be happy to contribute in this area.
> > Actually I believe this discovery part to be the real issue 
> with this
> > whole work, rather than the details of STUN itself.
> >
> > 2. Deployment issue: We do have several protocols in this area, for
> > instance NSIS. Their deployment does not look to be happening. For  
> > STUN
> > control to be useful, we would need real interest from some real  
> > NAT/FW
> > vendors. It's of course difficult to say how to verify this in a BOF
> > beyond matching people's e-mail addresses to NAT/FW product 
> brands :-)
> > Personally I can speak for a single client/host/device vendor only.
> >
> > Markus
> >
> >
> >> -----Original Message-----
> >> From: ext Magnus Westerlund [mailto:[e-mail]]
> >> Sent: 08 October, 2007 18:09
> >> To: TSV Area; Behave WG; mmusic (E-mail)
> >> Subject: [BEHAVE] BOF request under consideration: SAFE
> >>
> >> Hi,
> >>
> >> We ADs have received a request for a BOF in Vancouver: SAFE -
> >> Self-Address Fixing Evolution. See description below. I would
> >> appreciate any feedback on this. For public discussion please
> >> use the SAFE mailing list.
> >>
> >> Post: [e-mail]
> >> Subscribe: https://www1.ietf.org/mailman/listinfo/safe
> >>
> >> Draft:
> >> http://www.ietf.org/internet-drafts/draft-wing-behave-nat-contr
> > ol-stun-usage-03.txt
> >>
> >>
> >> SAFE - Self-Address Fixing Evolution
> >> ------------------------------------
> >>
> >> Chairs:
> >>  TBD
> >>
> >>
> >> ICE and its companion protocol STUN have been successfully
> >> deployed on the Internet for NAT traversal.  ICE and STUN have
> >> several characteristics which contribute to their success:
> >>
> >>  1. incremental deployment.  ICE and STUN are functional 
> without any
> >>     modifications to existing NATs.
> >>  2. nested NATs.  ICE and STUN work when there are multiple NATs
> >>     between a host and the Internet.
> >>  3. topology unaware.  ICE and STUN are not configured with
> >>     information about NATs, firewalls, or their locations -- only
> >>     with the IP address of a server on the Internet.
> >>  4. simple security model.  If a host behind a NAT is 
> allowed to send
> >>     a packet across the NAT, it is allowed to receive a response.
> >>  5. works on routed networks, which allows operation in both
> >>     enterprise networks and home networks.
> >>
> >> Other NAT traversal protocols do not share these
> >> characteristics, which hinders their widespread deployment.
> >> Specifically,
> >>
> >>  * incremental deployment is not possible with MIDCOM, NSIS-NSLP,
> >>    UPnP, or Bonjour.  With all of these protocols, both the NAT
> >>    and the endpoint have to support the same protocol.
> >>  * nested NATs are not possible with UPnP or Bonjour.
> >>  * topology awareness is required of MIDCOM.
> >>  * security must be established between the controlling entity
> >>    and the NAT for MIDCOM and NSIS-NSLP.
> >>  * Both UPnP and Bonjour use broadcast packets which don't work
> >>    well on routed networks.
> >>
> >> However, a drawback of ICE/STUN is its chatty keepalive
> >> traffic, which is a result of STUN not knowing the binding
> >> lifetime of its on-path NATs.  This chattiness causes a burden
> >> on servers and consumes network bandwidth, which is especially
> >> critical on wireless networks.  It is desirable to reduce this
> >> chattiness while still retaining the important characteristics
> >> of STUN and ICE.
> >>
> >> This BoF is intended to discuss one proposed technique,
> >> draft-wing-behave-nat-control-stun-usage, which nearly
> >> eliminates STUN's keepalive chatter and still preserves the
> >> desirable characteristics of STUN/ICE.
> >>
> >> The purpose of this BoF is to create a working group for 
> this effort.
> >>
> >>
> >> Agenda:
> >>  Introduction, Agenda ....................................  5
> >>  Summary of existing NAT traversal techniques ............ 40
> >>   (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS-NSLP, ICE)
> >>  draft-wing-behave-nat-control-stun-usage ................ 40
> >>  Q&A ..................................................... 25
> >>                                                    ----------
> >>                                                    total: 110
> >>
> >> Cheers
> >>
> >> Magnus Westerlund
> >>
> >> IETF Transport Area Director & TSVWG Chair
> >> 
> --------------------------------------------------------------------- 
> >> -
> >> Multimedia Technologies, Ericsson Research EAB/TVM/M
> >> 
> --------------------------------------------------------------------- 
> >> -
> >> Ericsson AB                | Phone [phone]
> >> Torshamsgatan 23           | Fax   [phone]
> >> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> >> 
> --------------------------------------------------------------------- 
> >> -
> >>
> >>
> >> _______________________________________________
> >> Behave mailing list
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/behave
> >>
> >
> >
> > _______________________________________________
> > SAFE mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/safe
> >
> 
> 
> 
> _______________________________________________
> SAFE mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/safe


_______________________________________________
SAFE mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/safe