On Wed, 2004-07-07 at 17:15, Florent Parent wrote: > > Section 5.4 > > Some NAT boxes will force-timeout mappings or have a very short timeout. > > The tunneling or the setup protocol used should be able to recover thus > > from both endpoint address and port changes without loosing packets. > > Yes. But "without loosing packets" need to be defined. e.g. if I have a > ping(v6) in a loop going out of my tunnel and the NAT state changes, I will > certainly loose ICMPv6 packets. Maybe you are referring to not loosing IPv6 > connections instead? Indeed, as when one changes an IP address overcoming loosing packets is not possible in most cases unless one implements sequence numbers which defies a lot of things. Minimizing the loss though should be an objective. <SNIP> > > To also mitigate attacks based on 'knowledge' of endpoint information eg > > by sniffing setup information packets it should be IMHO that the tunnel > > setup protocol is able to use some form of SSL/TLS mode thus making sure > > that the interaction between client and server is not readable maybe > > disclosing information that can be useful to attack the tunnel. > > Again as an option that can be enabled/disabled? Of course optional, though it should be highly preferred. There are a number of organisations that require you to change passwords every 3 months but sending those passwords in clear text is a defacto use ;) > > It could also explain the user how to disable the client program. > > The client-program might also want to ask the user if it wants to use > > native or tunneled connectivity maybe in case where the native > > connectivity is misconfigured, and thus not working. > > > > Section 5.10 > > Fortunatly this is a should, typically, from what I have seen at least, > > most ISP's don't allow their customers to change reverse DNS entries. > > Also, tunnels should be seen as 'transit networks', the /48 routed to the > > client should have a means of registering dns servers though. > > The current requirement has nothing about DNS prefix delegation. Are you > saying it should be supported in the protocol? It could be handy if the protocol could be used for it, then again there are a number of other established protocols (DDNS for instance) that could be used here, then again, distributing keys etc is not defined there thus putting it into this protocol to allow the registration > > > > Appendix A > > "The registered mode:" > > "- implementation SHOULD turn it off by default" > > Shouldn't asking the client once be a good option? > > Not following here. The user should be put to the question once if it wants a registered tunnel or not. If the question is not asked they will not use it. Greets, Jeroen
Attachment:
signature.asc
Description: This is a digitally signed message part