Subject: [secdir] comments on draft-irtf-rrg-recommendation-14

From: Sandra Murphy <[email-masked]>
Date: Thu, 28 Oct 2010 13:27:29 -0400 (Eastern Daylight Time)

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security area 
directors.  Document editors and WG chairs should treat these comments 
just like any other last call comments.

I unfortunately was off-net for a few days and got to this assignment 
rather late.  The document is long and covers a broad swath of material 
and I was not able to cover it deeply.

This document is a product of the rrg IRTF working group.  It summarizes 
15 different proposals for a new routing and addressing architecture for 
the Internet, with short summaries, critiques and rebuttals for each, and 
gives a final recommendation to the IETF for future direction.

With the breadth of scope of the document, there is no way for me to 
review each proposal's documents for security considerations.

The security considerations of *this* document itself is quite terse:

20. Security Considerations

    All solutions are required to provide security that is at least as
    strong as the existing Internet routing and addressing architecture.

Given the widely reported weakness of the "existing Internet routing and 
addressing architecture", this is a low bar indeed.  There are attempts in 
progress to attempt to improve the security of the Internet routing and 
addressing architecture.  I do not know what to suggest if these 
improvements leave the Internet with stronger security than is provided by 
these proposals.

The summaries of the different proposals devote little attention to the 
infrastructure security ramifications of the proposal.  Given the stated 
goal, perhaps no attention was necessary.

Many of these proposals include an encapsulation system, presenting the 
expected difficulties with end system authentication, filtering systems at 
boundaries, etc.  Some proposals addressed these concerns.  I am not sure 
if the security considerations section meant that the proposals were 
required to avoid weakening the end-host security protections already 
provided (ipsec, NAT, whatever).

The rrg wg came to consensus that a fundamental architectural feature is 
a separation of locator and identifier for any node.  Many of the 
discussed alternatives include a mapping system that produce a locator for 
a given destination identifier.

The mapping system would seem to be a very likely point of vulnerability, 
permitting traffic redirection for data exposure or blackholing, etc. 
Many proposals suggest a hierarchic architecture of the mapping system for 
scaling purposes.  I would presume that an authorization scheme for the 
mapping system would be essential, and that the hierarchy would be an 
important aspect of that scheme.  Of course, I can't tell much at this 
level of detail about how and if each proposals addresses this.  (One of 
the recommendations suggests communicating mapping info through bgp - I 
can not say at this point whether the SIDR suggestions for improving bgp 
security would be applicable.)

--Sandy

Nits:

    PMTUD  Path Maximum Transmission Unit Discovery: The process or
       mechanism that determines the largest packet that can be sent
       between a given source and destination with being either i)
       fragmented (IPv4 only), or ii) discarded (if not fragmentable)
       because it is too large to be sent down one link in the path from
       the source to the destination.

It should say "*without* being either", right?  A long sentence so I may 
have lost my place.

Several of the comments start using terms that are part of the wg 
deliberations, I'm sure.  But it makes reading the discussions and 
critiques obtuse.  In particular, "Core-Edge Separation" and "Core-Edge 
Elimination" seems to a well understood concept in the wg.  It needs to be 
defined somewhere.  A web search found references in some conference 
papers and in rrg mailing lists.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Oct 2010 22:22:21 +0100

Not really for Sandy, more for the ADs/Sam W:

Why are we doing a secdir review of an IRTF draft? That's
not required by any process I know of (speaking as an IRTF
RG chair).

Unless maybe the RRG asked for it, in which case, ignore
this.

Otherwise we should try filter the assignments for
irtf drafts since this is not the 1st time this has
happened. (Last time, I spotted it before someone did a
review.)

Ta,
Stephen.

On 28/10/10 18:27, Sandra Murphy wrote:
> These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these
> comments just like any other last call comments.
> 
> the Internet, with short summaries, critiques and rebuttals for each,
> and gives a final recommendation to the IETF for future direction.
> 
> addressing architecture", this is a low bar indeed.  There are attempts
> in progress to attempt to improve the security of the Internet routing
> and addressing architecture.  I do not know what to suggest if these
> improvements leave the Internet with stronger security than is provided
> by these proposals.
> 
> expected difficulties with end system authentication, filtering systems
> at boundaries, etc.  Some proposals addressed these concerns.  I am not
> sure if the security considerations section meant that the proposals
> were required to avoid weakening the end-host security protections
> already provided (ipsec, NAT, whatever).
> 
> discussed alternatives include a mapping system that produce a locator
> for a given destination identifier.
> 
> The mapping system would seem to be a very likely point of
> vulnerability, permitting traffic redirection for data exposure or
> blackholing, etc. Many proposals suggest a hierarchic architecture of
> the mapping system for scaling purposes.  I would presume that an
> authorization scheme for the mapping system would be essential, and that
> the hierarchy would be an important aspect of that scheme.  Of course, I
> can't tell much at this level of detail about how and if each proposals
> addresses this.  (One of the recommendations suggests communicating
> mapping info through bgp - I can not say at this point whether the SIDR
> suggestions for improving bgp security would be applicable.)
> 
> --Sandy
> 
> Nits:
> 
> Elimination" seems to a well understood concept in the wg.  It needs to
> be defined somewhere.  A web search found references in some conference
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
>

---

From: "Polk, William T." <[email-masked]>
Date: Thu, 28 Oct 2010 21:15:49 -0400

Stephen,

We have not changed the process.  There was a tools error - the draft ended up on the agenda as an informational RFC on the IETF stream.  I actually pointed this out to the secretariat so that the document was moved to the right part of the agenda, but I did not notice that this document got assigned for a secdir review.  Sandy was diligent and did the review before the telechat.

We need to figure out why the tools error is occurring and get this corrected.  Adding a manual step for irtf stream filtering would be a real burden for Sam.

Thanks,

Tim

On 10/28/10 5:22 PM, "Stephen Farrell" <[email-masked]> wrote:

Ta,
Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Oct 2010 15:51:06 +0100

On 29/10/10 02:15, Polk, William T. wrote:
> Stephen,
> 
> We have not changed the process.  There was a tools error

That's grand. I just wanted to call it out, in case.

Cheers,
S.

>  - the draft
> ended up on the agenda as an informational RFC on the IETF stream.  I
> actually pointed this out to the secretariat so that the document was
> moved to the right part of the agenda, but I did not notice that this
> document got assigned for a secdir review.  Sandy was diligent and did
> the review before the telechat.
> 
> We need to figure out why the tools error is occurring and get this
> corrected.  Adding a manual step for irtf stream filtering would be a
> real burden for Sam.
> 
> Thanks,
> 
> Tim
> 
>

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 29 Oct 2010 14:33:19 -0400 (EDT)

> corrected.  Adding a manual step for irtf stream filtering would be a real
> burden for Sam.

It may not be so burdensome -- seeing the doc name helps.  :-)  In 
this case, I did a double-take and rechecked the IESG agenda.  And, 
seeing where the doc was, decided to go ahead and send it out.

-- Sam