Re: [dtn-interest] [Fwd: Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct]

["Michael Welzl" <[e-mail]>]

> >>>> pages 12/13: what is the rationale behind delivery options such as
> >>>> these:
> >>>>
> >>>>    - Report When Bundle Forwarded - requests a Bundle Forwarding
> >>>> Status
> >>>>       Report be generated when the subject bundle departs a DTN node
> >>>>       that has forwarded it.
> >>>>
> >>>>    - Report When Bundle Deleted - requests a Bundle Deletion Status
> >>>>       Report be generated when the subject bundle is deleted at a DTN
> >>>>       node.
> >>>>
> >>>> If I would propose something like these reports for the general
> >>>> Internet,
> >>>> it would immediately be rejected for obvious reasons ("how would
> >>>> this scale?
> >>>> why do you need this?" etc.) - why would this then be acceptable
> >>>> for a DTN?
>
> I'm mainly replying to this question because I think it's the crux of the
review.

I agree - but note that there's one more technical issue which I addressed:
the fragmentation mechanism. But first things first.


> I think the key idea here is that bundle status reports constitute a thin
> “application”-layer diagnostic protocol on top of the bundle protocol in
> (I believe) exactly the same way that ICMP messages constitute a thin
> diagnostic protocol on top of IP.  BSRs are the payloads of bundles
> just as ICMP messages are the data portions of IP datagrams.  They
> are useful in more or less the same way that ICMP messages are useful.

That's also how I understood it.


> To quote from RFC 792:
>
> “ICMP, uses the basic support of IP as if it were a higher level protocol,
> however, ICMP is actually an integral part of IP, and must be implemented
> by every IP module.  ICMP messages are sent in several situations: for
example,
> when a datagram cannot reach its destination, when the gateway does not
have
> the buffering capacity to forward a datagram, and when the gateway can
direct
> the host to send traffic on a shorter route.”
>
> Substitute BSR for ICMP message and Bundle Protocol for IP and I think you
> get more or less what the DTN documents say.

But "when a gateway forwards a datagram" is not a part of this text, and
"when a
gateway does not have the buffering capacity" seems to me to refer to Source
Quench,
which is now known to be a bad idea.


> Now, that is not to say that BSRs don’t constitute a potential DOS attack,
in
> part because -- as Michael points out -- BSRs can be triggered by some
kinds
> of wholly nominal events as well as by anomalies.  We haven’t given a lot
of
> thought to ways of mitigating this threat, and I think we should.  Here’s
a suggestion.
>
> The architecture and Bundle Protocol documents currently define the
circumstances
> under which BSRs must be issued.  I propose that we simply qualify all
those
> “must” statements with the additional clause “and a Bundle Reporting
License [BRL]
> is known to be applicable.”  A BRL is a 4-tuple of {my own EID, source
EID,
> report-to EID, status reporting flag}, and it is applicable if and only if
its members
> characterize the BSR issuance opportunity.  The propagation of BRLs is
outside

Hm, does that mean that any node that generates a BSR of any kind would have
know in advance whether that message can reach its destination? That doesn't
seem like a realistic assumption to me. Or am I misinterpreting the "members
characterize the BSR issuance opportunity" part?


> the scope of the Bundle Protocol; somebody will come up with a
> protocol for it when we decide it’s needed.  Meanwhile all BRLs can
> be hard-coded or loaded from a configuration file or whatever.
>
> If a rogue bundle node starts sending out bundles with status reporting
> requested, no BSR traffic storm will ensue because no BRLs are
> applicable.  If a rogue bundle node impersonates an authentic one,
> then you get a DOS attack – but you can get that anyway if you don’t
> have bundle authentication implemented, and if you do then you discard
> the bundles before issuing any BSRs for them.
>
> It’s a relatively small and simple change to the documents that addresses
> the problem without rushing to spell out an elaborate comprehensive
solution.

...as would be the removal of the two messages above   :-)


> Michael, would this address your concern?

If this is feasible, yes. In any case, it's a step in the right direction
IMO.

Cheers,
Michael