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

[Scott Burleigh <[e-mail]>]

Stephen Farrell wrote:
> 
> Just to explain. The new scheme for IRTF RFC publication
> requires a poll of the IRSG (the set of RG chairs plus a
> few others). If there're negative polls then those comments
> should be discussed and hopefully resolved. (If not resolved
> then in the end the IRTF chair makes a call I think.)
> 
> For those familiar with current IETF WG practice this is
> sort of like a combined IESG review and IETF last call.
> 
> So the thing to do here is for one of the authors of the
> arch draft to respond to Michael's comments. (Please make
> sure to cc' both the list and Michael.)
> 
> Stephen.
> 
> FYI: there's another comment to come from Tom Henderson.
> 
> Michael Welzl wrote:
>> -----Forwarded Message-----
>>
>>> From: Aaron Falk <[e-mail]>
>>> To: Michael Welzl <[e-mail]>
>>> Cc: Kevin Fall <[e-mail]>, Stephen Farrell 
>>> <[e-mail]>
>>> Subject: Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct
>>> Date: 30 Oct 2006 08:41:11 -0800
>>>
>>> Michael-
>>>
>>> Please forward your review to the RG mailing list as per draft-irtf- 
>>> rfcs.  Stephen Farrell is the draft shepherd and will coordinate  
>>> resolution of your comments.
>>>
>>> --aaron
>>>
>>> On Oct 30, 2006, at 2:38 AM, Michael Welzl wrote:
>>>
>>>> o  'not ready to publish' -- requires a thorough read, reasonably
>>>>    detailed review, and actionable comments.
>>>>
>>>> See my review below - and sorry that it took me so long!
>>>>
>>>> Cheers,
>>>> Michael
>>>>
>>>> ---
>>>>
>>>> I am not an expert on DTN (but this probably makes me a good guinea
>>>> pig for a document such as this one), and therefore don't know all
>>>> the reasons that led to design decisions in this document; such
>>>> specifications are not necessarily the right place for justifying
>>>> design decisions, and there may be conference or journal papers
>>>> where such justification is found, and which I may not know about.
>>>> Thus, if there are such documents, it would be all right in my
>>>> opinion to simply point to them, as an aid to readers who would
>>>> like to understand a bit more about the design.
>>>>
>>>> If there isn't any justification in any such documents regarding
>>>> the points I'm raising about delivery options and bundle status
>>>> reports, I would however regard this as critical.
>>>>
>>>>
>>>> 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 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.

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.

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 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.

Michael, would this address your concern?

I'd like to leave the other questions for somebody who's closer to the text of the Architecture document -- Leigh or Kevin?

Scott

>>>> Deletion could be done because of congestion, so you require a message
>>>> to be generated during times of congestion - which smells like  
>>>> source quench.
>>>> I don't have a problem with end-to-end ACKs like "Report When Bundle
>>>> Acknowledged by Application", but these reports of intermediary nodes
>>>> seem strange to me.
>>>>
>>>> The same comments obviously apply to the Bundle Status Reports that go
>>>> with these options, e.g. "Bundle Deletion" on page 14.
>>>>
>>>> I could imagine that such intermediate reports would be useful for
>>>> per-hop retransmissions as foreseen by the custody transfer, but they
>>>> reports do not appear to be designed (solely) for such use, as there
>>>> is a specific signal dedicated to custody transfer, and the report-to
>>>> EID *may* differ from the source's EID. On page 13, it is stated that
>>>> Bundle Status Reports correspond approximately to ICMP - thus,
>>>> "Bundle Deletion" should not be regarded as a per-hop NACK (which
>>>> I could accept as a necessary message, if it is sent to no other
>>>> node than the custodian) but rather as an  ICMP-style "packet dropped"
>>>> or "packet received" message. Having such a feature strikes me as
>>>> bad design in no matter what network, as it is not cumulative in
>>>> nature and therefore implicitly assumes up to 50% of the bundles
>>>> in the network to be signaling messages of a "report" nature (i.e.
>>>> not a necessary element of a specific scheme such as per-hop or
>>>> end-to-end retransmission).
>>>>
>>>> Combined with the ability of arbitrary nodes to register for
>>>> reception of data for a particular EID (multicast support),
>>>> I imagine that these per-hop, per-bundle reports would open
>>>> the door for interesting DoS attacks.
>>>>
>>>> It also seems to me that the problem which is described in the last
>>>> paragraph on page 19 indicates that something is wrong with this
>>>> design. If the only ACK to the source would be of an end-to-end
>>>> nature, the problem would not occur, and why would a source need
>>>> earlier loss notifications when it can request custody transfer?
>>>> If the delay is too large for end-to-end retransmissions to be
>>>> useful, the source is probably not the node that should retransmit
>>>> anyway.
>>>>
>>>>
>>>>
>>>> page 15:
>>>>> The payload block indicates information about the contained payload
>>>>> (e.g. its length) and, somewhat unusually, includes the payload
>>>>> itself.  In addition to the fields found in the primary and payload
>>>> I suggest to remove "somewhat unusually" here. It caused me
>>>> to wonder why this is so unusual, while it doesn't really
>>>> matter anyway whether this is unusual or not.
>>>>
>>>> page 17, reactive fragmentation:
>>>>> the previous-hop sender may learn that only a portion of the bundle
>>>>> was delivered to the next hop, ..
>>>> How? No such report is defined.
>>>>
>>>> The description of Reactive Fragmentation should probably
>>>> be more detailed, perhaps using an example to explain the process.
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [e-mail]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>