Soo... if I want to comment on Jon Udell's post on Known from my own Known site... do I just put in a link to his post: http:/
November 14, 2014 archive
Nov 14
Soo… if I want to comment on Jon Udell’s post on Known from my own Known site… do I just put in a link to
Nov 14
Pleased to see that former neighbor Jon Udell is on Known as http://judell.withknown.com/
Pleased to see that former neighbor Jon Udell is on Known as http:/
Nov 14
Ello Adds Feature To Share Posts Out To Other Social Networks
The team over at Ello yesterday added the ability to share out posts you write on Ello to other social networks. When you are logged in to Ello, there is now a small circle-and-arrow icon below a post:
When you click/tap the icon you get the typical kind of "social sharing" box that you see on many social networks:`
You click on the social network to which you want to share and you get the usual kind of sharing windows you see for that given social network.
As co-founder Paul Budnitz notes, there was internal discussion about whether to offer this capability, but they decided:
On the other hand, we've have had many requests from Ello users for this function — especially from people who want to make Ello the central place for all their online activity, and need to post out to friends and followers who are still using other networks.
It will be interesting to see how widely this gets used and whether this is an incentive for people to use Ello as one of the places they primarily post content.
If you use Ello, what do you think about this feature?
UPDATE: The Ello team also released a wide range of other interesting features and fixes.
If you found this post interesting or useful, please consider either:
- following me on Twitter;
- adding me to a circle on Google+;
- following me on Ello;
- following me on App.net;
- subscribing to my email newsletter; or
- subscribing to the RSS feed.
Nov 14
Deploy360@IETF91, Day 5: IDR (Securing BGP), IPv6 and heading on to ION Tokyo
As the final day of IETF 91 opens there are only a few sessions left on the long IETF 91 agenda. For us at Deploy360, our focus will mainly be on the Inter-Domain Routing (IDR) and IPv6 Maintenance (6MAN) meetings happening this morning. Read on for more information…
NOTE: If you are not in Honolulu but would like to follow along, please view the remote participation page for ways you can listen in and participate. In particular, at this IETF meeting all the sessions will have Meetecho coverage so you can listen, watch and chat through that web interface. All agenda times are in HST, which is UTC-10 (and five hours earlier than US Eastern time for those in the US). I suggest using the “tools-style” agenda as it has easy links to the chat room, Meetecho and other documents for each session.
In the 9:00-11:30 HST block today the Inter-Domain Routing (IDR) is meeting in Coral 2 and it will be, as I understand it, a joint meeting with the SIDR working group that will focus on the proposed BGPSEC protocol. The agenda is:
- BGPSEC background/goals/context, Sandy Murphy
- BGPSEC protocol walk-through, Matt Lepinski
- BGPSEC protocol time, space analysis, K. Sriram
- BGPSEC issues for implementors, John Scudder
It should be an interesting session that ties in well with our Securing BGP topic area.
Simultaneously over in the large Coral 3 room, the IPv6 Maintenance Working Group (6MAN) has a very full agenda of proposals to improve how IPv6 works. For IPv6 fans such as me, this looks to be a great set of discussions!
The final block of sessions from 11:50-13:20 HST does not have any meetings directly tied to the topics we cover here, but I’m intrigued by a document in the Internet Area Open Meeting about tunnels in the Internet’s architecture that will probably be a good session to listen to.
And with that… our time here at IETF 91 in Honolulu will draw to a close. We’ll have the Internet Society Advisory Council meeting this afternoon… and then we are all heading to Tokyo to present about IPv6, DNSSEC, BGP, BCOP and more at our ION Tokyo event on Monday! (And you can watch ION Tokyo live via a webcast.)
Thanks for following us this week and to all those who greeted us at IETF 91! See you next time in Dallas!
P.S. Today’s photo is from Jared Mauch and used with his permission. NBC Universal, who sponsored the IETF 91 Welcome Reception, gave a stuffed “minion” out to anyone who wanted to have one. Give some engineers something fun like this and… well… photos are bound to happen! Jared had a good bit of fun coming up with some photos – you can see his “Minions” photo stream – and the minons were present in many other photos, such as this one I took.
See also:
Relevant Working Groups
We would suggest you use the “tools-style” agenda to find links to easily participate remotely in each of these sessions.
IDR (Inter-Domain Routing Working Group) WG
Friday, 14 November 2014, 0900-1130 HST, Coral 2
Agenda: https://datatracker.ietf.org/meeting/91/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/
6MAN (IPv6 Maintenance) WG
Friday, 14 November 9am-1130am, Coral 3
Agenda: https://datatracker.ietf.org/meeting/91/agenda/6man/
Documents: https://datatracker.ietf.org/wg/6man/documents/
Charter: https://datatracker.ietf.org/wg/6man/charter/
For more background on what is happening at IETF 91, please see our “Rough Guide to IETF 91″ posts on the ITM blog:
- Overview: Nerds Return to Paradise
- Bandwidth, Scalability & Internet Performance
- IANA Transition
- DNSSEC, DANE, and DNS Security
- IPv6
- Routing Resilience & Security
- Strengthening the Internet
- Trust, Identity, and Privacy
If you are here at IETF 91 in Honolulu, please do feel free to say hello to a member of the Deploy360 team. And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.
Nov 14
Make Encryption The Norm For All Internet Traffic, Says The Internet Architecture Board (IAB)
The Internet Architecture Board announced a new “Statement on Internet Confidentiality” yesterday that calls on “protocol designers, developers, and operators to make encryption the norm for Internet traffic“. The statement, distributed via email by IAB Chair Russ Housely, goes further in urging those who design and develop new protocols “to design for confidential operation by default“.
The strong statement, republished below, represents the continued evolution of the thinking of the wider technical community, as represented by the IAB and the IETF, that in light of the disclosures of massive pervasive monitoring of the Internet (see RFC 7258) the technical infrastructure of the Internet needs to be strengthened against those attacks.
As the IAB statement notes, such a move to make encryption the default will have impacts on some aspects of current network operations, but the statement represents the very public commitment by the IAB to help create the conditions under which, as it says, we can “move to an Internet where traffic is confidential by default.”
From our perspective here at Deploy360, we definitely welcome this statement as it will help the overall security of the Internet. Within the topics we cover here, we encourage developers to look at adding TLS to all their applications, and we encourage network operators to do all they can to help their customers use TLS-encrypted applications wherever possible. We are also looking forward to continued discussions such as those held in the DPRIVE Working Group this week at IETF 91 that will improve the confidentiality and privacy of DNS interactions as well as those within the routing infrastructure.
Here is the full IAB Statement on Internet Confidentiality:
IAB Statement on Internet Confidentiality
In 1996, the IAB and IESG recognized that the growth of the Internet depended on users having confidence that the network would protect their private information. RFC 1984 documented this need. Since that time, we have seen evidence that the capabilities and activities of attackers are greater and more pervasive than previously known. The IAB now believes it is important for protocol designers, developers, and operators to make encryption the norm for Internet traffic. Encryption should be authenticated where possible, but even protocols providing confidentiality without authentication are useful in the face of pervasive surveillance as described in RFC 7258.
Newly designed protocols should prefer encryption to cleartext operation. There may be exceptions to this default, but it is important to recognize that protocols do not operate in isolation. Information leaked by one protocol can be made part of a more substantial body of information by cross-correlation of traffic observation. There are protocols which may as a result require encryption on the Internet even when it would not be a requirement for that protocol operating in isolation.
We recommend that encryption be deployed throughout the protocol stack since there is not a single place within the stack where all kinds of communication can be protected.
The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations, and to make them encrypted by default. We similarly encourage network and service operators to deploy encryption where it is not yet deployed, and we urge firewall policy administrators to permit encrypted traffic.
We believe that each of these changes will help restore the trust users must have in the Internet. We acknowledge that this will take time and trouble, though we believe recent successes in content delivery networks, messaging, and Internet application deployments demonstrate the feasibility of this migration. We also acknowledge that many network operations activities today, from traffic management and intrusion detection to spam prevention and policy enforcement, assume access to cleartext payload. For many of these activities there are no solutions yet, but the IAB will work with those affected to foster development of new approaches for these activities which allow us to move to an Internet where traffic is confidential by default.
We’re looking forward to working with all of you there to bring about this Internet where traffic is encrypted by default!
