Re: [manet] Stephen Farrell's No Objection on draft-ietf-manet-dlep-26: (with COMMENT)

[Rick Taylor <[e-mail]>]

On Thu, 2016-12-15 at 15:22 +0000, Stephen Farrell wrote:
> Hiya,
> 
> On 15/12/16 15:12, Rick Taylor wrote:
> > 
> > Hi Stephen,
> > 
> > Thanks for the comments, some answers inline...
> > 
> > On Thu, 2016-12-15 at 06:39 -0800, Stephen Farrell wrote:
> > > 
> > > Stephen Farrell has entered the following ballot position for
> > > draft-ietf-manet-dlep-26: No Objection
> > > 
> > > - 5.1: Is a modem supposed to ignore peer discovery
> > > signals from routers with which the modem does not have a
> > > TCP connection?
> > Peer Discovery is a UDP-based mechanism that is designed to run
> > before
> > a TCP-based session is established, much like UPnP or mDNS.
> Sure, but my question stands doesn't it? As written
> a modem could decide to drop the current connection
> or ignore the signal. Don't you need to say?

Sorry Stephen, I misunderstood your question.

If the modem supports multiple simultaneous DLEP sessions with
different routers, then it may start another parallel DLEP session.  If
it doesn't then it probably shouldn't terminate any existing session,
but that's an implementation decision.

The bottom line is that we purposefully haven't addressed the multiple
simultaneous sessions per DLEP peer issue in this draft, as it isn't
clear to the WG how exactly it would work in a sensible way.  However,
text such as the paragraph above could be added to Section 5.1 if you
think it aids clarity?

> 
> > 
> > 
> > > 
> > > 
> > > - 10.7: This says: "If the modem is capable of
> > > understanding and forwarding this information (via
> > > mechanisms not defined by DLEP)," I don't get why that's
> > > here, can you explain? If modem-modem comms is part of
> > > DLEP deployments (even if not fully spec'd) then that does
> > > change the security model.
> > DLEP only defines the conversation between a local router/modem
> > pair.
> >  How or what a modem sends over the air to another modem is
> > intentionally out of scope.
> That's why I don't get why the text sorta muddies the
> waters with the above quoted text.
> 

The purpose of that text was to explain to an implementer what was
required by DLEP to make the whole address thing work, without telling
the implementer how they had to do it (or secure it).

> > 
> > 
> > > 
> > > 
> > > - 10.9 and elsewhere: none of these messages have anything
> > > like a cookie. Why not? That'd help mitigate potential off
> > > path attacks, where we currently depend solely on TTL=255
> > > (and TLS, which seems to not be some people's favourite;-)
> > To be frank - we never considered a cookie as a security mechanism.
> >  Personally I considered an attacker capable of successfully
> > injecting
> > octets into an existing TCP stream would probably be able to hijack
> > a
> > cookie mechanism.
> > 
> > However, I am not a security expert, and if this is a viable
> > alternative to TLS (which is unpopular with implementers, and has
> > open
> > questions over certification) then it is definitely something that
> > should be considered.
> I'd need to think about the combination of 1-hop and offpath
> but there may be cases where it's useful e.g. to stop someone
> else on the same LAN from hijacking an existing session.
> 
> Cookie mechanisms are not really an alternative to TLS though,
> more a useful thing if one doesn't have TLS, if you see the
> difference I mean.
> 

I think cookies should be discussed, given that they haven't been yet.

I think some of this is being discussed in the other thread in this
list covering Alexey's discuss, so I will leave this alone.

Cheers,

Rick