Softwire Security Analysis and Requirements
RFC 5619

[Ballot discuss]
This document has a number of issues that should be addressed efore publication.

#1 the document does not clearly explain the scope or goal, or what form the follow-on
work will take...

#2 upper and lower case musts and shoulds are used seemingly interchangably.  Sorting
out the requirements is very difficult imho.

#3 Figure is mislabeled, I think... since the supporting text is all about the SI-SC
authentication model for hubs and spokes

#4 Section 3.4 talks about the "Softwire security protocol" but earlier text implied no mandatory to implement protocol would be specified.  Are these requirements for softwires, or for a new protocol?

[Note: I apologize for the brief nature of this discus.  I will add comments later in the week
to help ensure these issues are actionable...]

[Ballot discuss]
I have reviewed draft-ietf-softwire-security-requirements-07, and have
a couple of concerns that I'd like to discuss before recommending
approval of the document:

- Section 3 needs to be clearer that there are *two* different (and
incompatible) solutions for securing L2TPv2 with IPsec (see new text
in Section 10 of hs-framework-l2tpv2-12). Some of the details differ,
and the MUSTs etc. need to be aligned with hs-framework-l2tpv2.

- Sections 3.5.4.1 and 3.5.4.2: To me it seems the SPD and PAD entries
for IPv6-over-IPv4 and IPv4-over-IPv6 cases should be identical
(except replacing IPv4 addresses with IPv6 and vice versa) -- but
they're not. Why? (to me the entries in 3.5.4.1 look more
correct than 3.5.4.2 -- at least the SC PAD entry in 3.5.4.2
looks unrealistic, since usually the SC won't know SI_address
beforehand.)

- Section 4.4.2: It seems this isn't fully aligned with
softwire-encaps-ipsec, since it doesn't describe the
use-public-key-crypto-without-PKI approach.

- Section 4.2.2, 3rd paragraph: since softwires are created
dynamically by BGP, the paragraph should clarify that "pre-shared key"
here really means "group key" (same key in all routers), not pairwise
shared keys.

[Ballot discuss]
Has this document been reviewed by the Security Directorate?

The attack threat scenarios list in sections 3.3 and 4.3 mostly describe attacks on individual packets or flows; e.g.:

3.3:  1.  An adversary may try to discover identities by snooping data
      packets.

4.3:  1.  An adversary may try to discover confidential information by
      sniffing softwire packets.

Why is the scenario in 3.4 limited to just identities and not other confidential information?  I would expect that these packet attacks would be the same in both hub-and-spoke and mesh scenarios.

At the same time, I would expect there would be different attack scenarios based on the different security and trust models; for example, in the message exchange between the visited and home AAA services in the case of the hub-and-spoke scenario.

[Ballot discuss]
Has this document been reviewed by the Security Directorate?

The attack threat scenarios list in sections 3.4 and 4.3 mostly describe attacks on individual packets or flows; e.g.:

3.4:  1.  An adversary may try to discover identities by snooping data
      packets.

4.3:  1.  An adversary may try to discover confidential information by
      sniffing softwire packets.

Why is the scenario in 3.4 limited to just identities and not other confidential information?  I would expect that these packet attacks would be the same in both hub-and-spoke and mesh scenarios.

At the same time, I would expect there would be different attack scenarios based on the different security and trust models; for example, in the message exchange between the visited and home AAA services in the case of the hub-and-spoke scenario.

[Ballot comment]
WG history or details are not typically relevant for RFCs. Rephrase the
  introduction to make this about the technology rather than the WG.

draft-ietf-softwire-security-requirements-06

PROTO questionnaire for:
prepared by: Dave Ward (dward@cisco.com)

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Dave Ward

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, internationalization,
XML, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document
that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong WG consensus behind this document and no one that has
expressed concerns about its progression.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).
No.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative
references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area
Director in
the Last Call downref procedure specified in RFC 3967.

The references are split into normative and informative.


Protocol write-up for:
by Dave Ward, dward@cisco.com

Technical Summary

This document describes the security guidelines for the softwire
"Hubs
and Spokes" and "Mesh" solutions. Together with the discussion of
the
softwire deployment scenarios, the vulnerability to the security
attacks
is analyzed to provide the security protection mechanism such as
authentication, integrity and confidentiality to the softwire
control
and data packets.

Working Group Summary

The SOFTWIRE WG supports the development and advancement of this
document.


Protocol Quality

This document was thoroughly reviewed by WG chairs and WG members,
including those with expertise in security, IPv4 to IPv6
transitions and
interworking.

Dave Ward is the WG chair shepherd. Mark Townsley is the
responsible Area
director.