Jan 12, 2015 Hangout minutes
- charlie
- stan
- lotte
charlie - I don't think we should delete the entire section, but apparently there is a lot of improvement that can be made; making clear what's optional and there have been requests to clarify what happens if some implement optional features and some don't. I wanted to discuss if we can close this issue before we get this done.
lotte - I'm not too fond of s 13, but we can keep it, but lets start with overhauling RREP_ACK.
charlie - RREP_ACK was added when I and loadng came into the picture.
stan - In terms of removing or keeping it, I don't have a dog in the race. If we close it, thats going to add to the political fight.
charlie - I didn't suggest that.
stan - But that's what I heard. Let me look at it, and we'll make proposals and figure out what it should ultimately be.
lotte -
[conversation]
charlie - What happens if some nodes implement reduced MC and some don't? Answer: if some implement it, and some don't, then the ones that dont implement it are going to work harder. Afaik, that's the only effect. That's a good scenario for interop things. Stan, you said that this info should be included in the text and I'll write that down.
stan - From what I remember, what started the discussion was the downref. And what we were going to do is remove it.
charlie - What lotte suggested was that we point out it exists and I am in favor of pointing it out, because it provides a big improval and it would be irresponsible for us to fail to point it out.
stan - The text that was presented... You've crossed over into the self-evident. The softer the recommendation, the better. We may have to remove it altogether.
charlie - okay
###issue #35
charlie - John pointed out that the aodvv2 way of doing it is ietf-conformant. However, it may make sense to point out the pitfalls of implementations using differnet constants. But its not top priority for me.
stan - I didn't hear a specific proposal.
charlie - (laughs) Thats because I didn't make one. Proposal: take each constant and add a paragraph saying what would happen if the constant changes, but that would be ome bloaty and should be in an appendix. But! It is valuable info.
stan - okay, then lets move on to the more important issues
charlie - can I make a digression?
lotte & stan - ok
charlie - We have 15-20 issues, most of them can be easily resolved, most challenging: security issues. Last call sghould be in march, we have to have a new version out this month and by then we need at least a proposal for a solution for each issue. I had a talk with adrian abt the security issues 5 months ago. On one hand, we need to adhere to sec standards. On the other, we have a political minefield. It's impossible for everone to be statisfied, and I'd like to adhere to what IETF people know how to do. IETF doesn't have a good track record for security stuff. In the case of aodv... What people wanted was to be able to communicate. And if you have a military scenario, your primary goal is communication and then security. So my resolution is that whenever possible, communications should be secure, but they should work even without security. Now, security wil get you publications, but you can get work done without an iron-clad security scheme. Goal: write in the application statement that AODVv2 can be operated with different security levels.
stan - Recommendation: What we did in DLEP: you said earlier that the IETF had a checkered past in terms of security. Point taken. We should be able to rely on the underlying security RFCs (dlep example: TLS). If we can rely on the existing mechanisms, we did what we needed to do.
charlie - Why don't we do that for AODVv2? Can you write that up?
stan - Yes!
charlie - Ok cool, but let's get feedback from Stephen Farrell on this first.
stan - Fine. So from our perspective, these are RFC5444 issues, not ours. The security occurs at the transport level.
charlie - Let's do this.
stan - What we also need to think about is that soon, in this environment, AODVv2 is just another application sitting on top of RFC5444. Is there anything that we can do above that? Like checksums, hashes, certificates that help with authentification of valid communication partners...
charlie - we have some security docs. off the top of my head: IPsec. when I read it I thought it was tedious –
stan - --Stop. IPsec is transport. Boom, we're done. My question was more: there was recent work in OSPF where they introduced additional hashes for autzh between OSPFs and that wouzld be above transport.
charlie - we could intoduce a new message TLV with an auth hash. I can write those down, but first we'll have to pin down what's actually the objective. In the case of OSPF, thats not a security feature, but [lost track here, sorry -lotte]
stan - I don't mean to reply thats a requirement for AODVv2, I'm just trying to foster innovation here. All I'm asking is: can we do something cool aside from relying on transport?
charlie - [didn't type fast enough again, sorry -lotte]
stan - I'm more than willing to accept the notion that transport level security is accurate. And if RFC5444 security sucks, the 5444 team has to fix it.
charlie - Homework: let's all read the rfc5444 security document.
charlie -
[more conversation that exceeded my typing speed]
all - read rfc5444 sec
charlie - Add remark what happens if some implementations use RFC 6621 and some don't
stan - write down underlying security trick
lotte - Distcuss Packet things on Mailing List