Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
RFC 6371

Note: This ballot was opened for revision 11 and is now closed.

(Adrian Farrel) Yes

Comment (2010-12-31 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Three Directorate reviews have been addressed, but a few non-blocking comments remain that should be addressed to improve the document before it is published as an RFC:

SecDir - vincent.roca@inrialpes.fr

> However there's a (naive) question which you didn't answer: is it
> realistic to assume the physical network can be secured? Are there
> known weaknesses in the MPLS infrastructure? Nothing is said in
> the I-D.
>
> Another point (from -10). It is said:
>
>         However
>         it should be observed that the combination of the need for
>         timeliness of OAM transaction exchange and all permutations of
>         unique MEP to MEP, MEP to MIP, and intermediate system
>         originated transactions mitigates against the practical
>         establishment and maintenance of a large number of security
>         associations per MEG either in advance or as required.
>
> The reasons mentioned here to justify nothing is done is critical.
> Only two reasons are listed: timeliness and combinatorial motivations.
> In your answer you also mention the high transmission frequency of
> heartbeats. This is not mentioned. Something else?

GenArt - david.black@emc.com

> The authors have addressed most of the items noted in the Gen-ART review
> of the -09 version, but there is one item that could still use some attention.  
> From the original review:
>
>	[D] The security considerations section should include specific mention
>	of injection of LKI request OAM packets as a vector for a denial-of-service
>	attack (this is an obvious way for a man-in-the-middle to quickly cause
>	serious havoc).  That would be a good specific example to add to the end
>	of the current security considerations paragraph that requires the network
>	to be physically secure against man-in-the-middle attacks.
>
> This has not been done.  While the security considerations section does
> cover the countermeasures necessary to prevent this attack, I prefer security
> considerations sections that include examples of things that can go badly
> wrong when implementers don't pay attention when the examples are simple.
> That preference is a matter of style/taste that I'll leave to the responsible AD's
> judgment

RtgDir - thomas.morin@orange-ftgroup.com

> I replied to Dave Allan that my current 
> feeling, after going through today's revision of the OAM framework 
> document, is that the comments I made are only partially addressed.

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss) No Objection

(Ralph Droms) No Objection

(Russ Housley) No Objection

Comment (2011-01-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  The Gen-ART Review by David Black lead to some document updates.
  However, one comment was not addressed.  Please consider updates
  to the security considerations section.  David said:
  >
  > [D] The security considerations section should include specific
  > mention of injection of LKI request OAM packets as a vector for a
  > denial-of-service attack (this is an obvious way for a man-in-the-
  > middle to quickly cause serious havoc).  That would be a good
  > specific example to add to the end of the current security
  > considerations paragraph that requires the network to be
  > physically secure against man-in-the-middle attacks.
  >
  While the security considerations section does cover the
  countermeasures necessary to prevent this attack, it seems like
  a good idea to document something that can go badly wrong when
  implementers do not pay attention.

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection